应届生马上毕业了,总免不了求职面试这个环节。身为网络工程师,在面试时,难免都会被问到TCP/IP这玩意儿。
对于TCP/IP,很多网络工程师又爱又恨。
学网工,肯定都逃不开这个概念,要学的细致。但是实际工作中,很少能用到这类的理论概念,这不只是一个网工在吐槽。
但是,这个情况不只是网工一个人有,任何一个行业、岗位都是要从理论开始学起的。
职场发展到后期,不少人会接触到管理,要学管理,也得是从一堆理论学起,晦涩难懂,大多数在实际工作中一样没法发挥啥真正效用。
那为什么要学?必须是有理由的。
学习管理学理论,是为了让你更好理解管理到底是什么;
学习网络基础知识,也是为了让你理解网络到底是什么。
只有理解了“是什么”,你才能进一步深究“为什么”,最后反馈到你的工作层面,折射出来的每个“怎么做”,就是你在学习过程中成果展示了。
想要系统学习TCP/IP的小友,也欢迎私信老杨,网络基础其实在HCIA/CCNA认证课程中就有系统涉及到。
如果对考证有很多疑惑,苦于没有人询问的小友,也欢迎私信老杨,获得我的解答。
既然,了解网络基础是每个网络工程师职业发展的必然要求,那么,你的TCP/IP了解到什么程度,需要补充哪些部分,你又知道吗?
今天这篇老文重温,再为你梳理一遍关于TCP/IP那些事儿。
TCP的中文名叫做传输控制协议,是供已经连接因特网的计算机进行通信的通信协议
计算机通信协议是对那些计算机必须遵守以便彼此通信的的规则的描述。TCP是互联网协议之一,也是主要的协议之一
为啥?
因为它起源于最初的网络实施,在网络实施中,它对互联网协议起到了重要的补充作用。因此,整个套件通常被人称呼为TCP/IP。
TCP/IP 定义了电子设备(比如计算机)如何连入因特网,以及数据如何在它们之间传输的标准。
TCP主要是给在用IP网络通信的主机上运行的应用程序之间,提供一种可靠、有序且经过错误检查的八位字节流传递。万维网、文件传输、远程管理等主要互联网应用都依赖于TCP。
如果是那种不需要靠数据流服务的应用程序,就可以使用UDP(用户数据报协议),它和TCP(传输控制协议)不同,前者强调降低延迟,后者强调可靠有序。
再说一点:TCP负责发现传输的问题,一有问题就发出信号,要求重新传输,直到所有数据安全正确地传输到目的地。而IP则是给因特网的每一台电脑规定一个地址。
有小白看到这里会问,那为啥计算机里一定要用到“xx协议”来传输信息呢?
因为单一的计算机并没有办法为人类发挥出最大的效用,只有把一台又一台的电脑连接起来,才能发挥出我们现在的功效。
这个连接不仅仅是单纯的网络连接,连起来也并不是简单的用电线把你的心和我的心串一串就可以解决的,那咋整?
举个例子:
每个电脑都运行着不同的操作系统,来给你提供对应的服务,对吧?
那么,电脑基于不同的系统,它们对于同个信息的表达是完全不一样的,就想美国人说Good Morning,日本人说哦害哟,我说早啊大兄弟。
那语言不通,不能友好交流,就得想个办法,我们一起制定一个共通的规则来进行交流就行了嘛。
于是TCP/IP这样的协议就出现了。
计算机因为有了这类型的很多协议,就像人类学了多门外语一样,就终于可以和其他的计算机终端放飞自我的交流了。
今日文章阅读福利:《TCP-IP详解卷一:协议》
如果你想更加系统的TCP/IP技术 ,也欢迎私信老杨,发送暗号“TCP”,我会把老网工常看的TCP/IP经典入门书籍发送给你,以作参考。
讲到TCP的诞生,就要回顾到1974年的那个夏天。
卡恩描述了一种使用网络节点间分组交换来共享资源的互联网协议,这就是TCP/IP的雏形
1974年的那个冬天,卡恩和瑟夫的第一份tcp协议详细说明正式发表。
当时,他们做了一个试验,将信息包通过点对点的卫星网络,通过陆地电缆,再通过卫星网络,然后由地面传输,贯串欧洲和美国,经过各种电脑系统,全程9.4万公里,竟然没有丢失一个数据位!
这样的远距离可靠数据传输,证明了TCP/IP协议的成功。
1983年元旦,运行了比较长时间的、曾被人们习惯了的NCP被停止使用,从此以后,TCP/IP协议就成了因特网上所有主机间的共同协议,被作为一种必须遵守的规则被肯定和应用。
介绍完了TCP到底是个啥,现在我们来讲讲,TCP这个“握手”是怎么个回事儿。
“握手”你可以理解为是TCP发功时所需要的仪式。
因为TCP常常用来发送大批量的数据,所以,为了提供可靠的的传送服务,TCP在发送数据之前,都需要用一种特定的顺序将数据包编号,并将这些数据包传送给目标,再确认消息。当对应的程序收到数据后,确认收到也需要用到TCP。
其实呢,三次握手就是为了对每次发送的数据量进行跟踪与协商,确保数据段的发送和接收同步,根据所接收到的数据量而确认数据发送、接收完毕后何时撤消联系,并建立虚连接。
那说了半天,到底握手是怎么握?
Step 1
TCP客户端准备发送一个syn段,用来指明客户打算链接的服务器端口以及isn(初始序号)。那么这个syn就被称为“报文段1”。
Step 2
那么,接下来,TCP服务端就会发回包含TCP服务端isn的syn段(即报文段2)作为回应。与此同时,TCP服务端会将确认序号设置为TCP客户端的isn+1,以对TCP客户端的s y n报文段进行确认。
Step 3
最后,TCP客户端也必须将确认的序号设置为TCP服务端的isn+1,作为对TCP服务端syn报文段的确认(即报文段3)这三个报文段就代表了连接的建立,而这个过程,就是TCP的三次握手(three-wayhandshake)。
当有人谈论这个问题的时候,实则是在谈论:
当 TCP 服务端发送连接请求确认报文段之后,当 TCP 客户端收到这个报文,其实就算建立连接了,这个时候直接发送数据不就行了,为什么还要再次发送一个 TCP 普通确认报文段呢?这就这个问题的“真实翻译”。
我们从两个角度来解释一下:
01 过程论证
我们就把这个过程简单点说吧,别整的那么复杂。
我们假设一下,如果只握手两次,会是什么情况?
假设,客户端发送的第一个连接请求没有成功,那服务端就没办法收到这个报文段,对吧?
你如果给女朋友发微信没发出去,肯定会再发一次啊。那客户端也是这么想的啊,它准备重新发送连接+请求报文段,那,服务器这下可算收到这个报文段了,进入连接建立好了状态。
客户端这个时候,也进入了连接,建立状态,可以进行数据传输了对吧?
但是呢,第一次的请求报文发送失败了,它悄咪咪的开始了超时重传,但客户端和服务端都早已建立好了链接,这个时候就导致TCP的服务端白白等待,浪费大量资源。
所以两次握手性价比不高,稳定性不足。
再简单一点举个例子:小明给小红发消息,小红呢,收到小明消息后,回了个消息。
那么证明了一点,就是小明发送能力没有问题,小红接收能力也没有问题。
那如果小明不回了,那小明到底看到没看到消息就无法判断了,小红就会想:到底是啥原因他不回我消息啊?我做错了啥啊?
所以啊,小明如果在再发一次消息给小红的话,就确认了小明其实看到了小红的消息,也确认了小明的接收能力是正常的。
同时,小红也的确真的给小明发了消息,所以他才会回复,所以小红的发送能力也是正常的。
这就是TCP非要握手三次不可的原因。
02 他人论证
还不懂得的,可以围观一下谢希仁版的《计算机网络》,它全面介绍了计算机网络的发展和原理体系结构、物理层、数据链路层等内容,应该没有没看过的IT人吧?
书里说过,TCP的握手,其实是为了保证双方互相明确对方收发能力的最低值。两次太少,四次太多,三次正正好。
而且啊,其实不论握手多少次都不能确认一条信道是“可靠”的,但通过3次握手可以至少确认它是“可用”的,再往上加握手次数,其实就不过是提高“它是可用的”这个结论的可信程度。
而且严格来说,三次握手其实是双方各握手一次,然后各确认一次,其中,一次握手+确认是合并在一起的,这才是“三次”的由来。