TCP/IP原理与相关内容总结
一.定义
TCP/IP(Transmission Control Protocol/Internet Protocol,传输控制协议/网际协议)是指能够在多个不同网络间实现信息传输的协议簇。
TCP/IP传输协议对互联网中各部分进行通信的标准和方法进行了规定,保证网络数据信息及时、完整传输。TCP/IP传输协议是一个四层体系,包含应用层、传输层。网络层以及数据链路层。其中应用层用来接收来自传输层的数据或者按照不同方式与要求将数据传输至传输层;传输层用来实现数据传输与共享;网络层负责网络中数据包的传送;数据链路层提供链路管理错误检测、对不同通信媒介有关信息细节问题进行有效处理等。其每层对应的协议如下图所示。
更详细的总结OSI以及TCP/IP各层有哪些协议:https://blog.****.net/cuiweitju/article/details/38761381
特点:
(1)协议标准是完全开放的,可以供用户免费使用,并且独立于特定的计算机硬件与操作系统。
(2)独立于网络硬件系统,可以运行在广域网,更适合于互联网。
(3)网络地址统一分配,网络中每一设备和终端都具有一个唯一地址。
(4)高层协议标准化,可以提供多种多样可靠网络服务。
二.数据链路层
主要工作:定义网络地址,区分网段,子网内MAC寻址,对于不同子网的数据包进行路由。
对电信号进行分组并形成具有特定意义的数据帧,然后以广播的形式通过物理介质发送给接收方。
以太网规定一组电信号就是一个数据包,一个数据包被称为一帧。一个完整的以太网数据包由首部、数据和尾部三部分组成,首部固定为14个字节,包含了目标MAC地址、源MAC地址和类型;数据最短为46个字节,最长为1500个字节,如果需要传输的数据很长,就必须分割成多个帧进行发送;尾部固定为4个字节,表示数据帧校验序列,用于确定数据包在传输过程中是否损坏。因此,以太网协议通过对电信号进行分组并形成数据帧,然后通过物理介质把数据帧发送给接收方。
网卡地址就是数据包的发送地址和接收地址,有了MAC地址以后,以太网采用广播形式,把数据包发给该子网内所有主机,子网内每台主机在接收到这个包以后,都会读取首部里的目标MAC地址,然后和自己的MAC地址进行对比,如果相同就做下一步处理,如果不同,就丢弃这个包。
封装成帧: 把网络层数据报加头和尾,封装成帧,帧头中包括源MAC地址和目的MAC地址。
透明传输:零比特填充、转义字符。
可靠传输: 在出错率很低的链路上很少用,但是无线链路WLAN会保证可靠传输。
差错检测(CRC):接收者检测错误,如果发现差错,丢弃该帧。
三.网络层
主要工作:定义网络地址、区分网段、子网内MAC寻址、对于不同子网的数据包进行路由。
3.1 IP协议
目的:用于区分两台主机是否属于同一个网络。
IP协议将这个32位的地址分为两部分,前面部分代表网络地址,后面部分表示该主机在局域网中的地址。如果两个IP地址在同一个子网内,则网络地址一定相同。为了判断IP地址中的网络地址,IP协议还引入了子网掩码,IP地址和子网掩码通过按位与运算后就可以得到网络地址。
IP数据包由首部和数据两部分组成,首部长度为20个字节,主要包含了目标IP地址和源IP地址,目标IP地址是网关路由的线索和依据;数据部分的最大长度为65515字节,理论上一个IP数据包的总长度可以达到65535个字节,而以太网数据包的最大长度是1500个字符,如果超过这个大小,就需要对IP数据包进行分割,分成多帧发送。
3.2 ARP、RARP协议
目的:ARP 是根据IP地址获取MAC地址的一种协议(在一个局域网内)。
在OSI模型中ARP协议属于链路层;而在TCP/IP模型中,ARP协议属于网络层。(百度百科里面开始简介部分介绍TCP/IP各层协议时说ARP、RARP是数据链路层的,但后面各层介绍时又划分在了网络层,之后查询相关博客应该是属于网络层)
ARP协议基本工作流程如下:
1.请求方发出一个携带ARP请求的链路层广播帧,包含了目的主机的IP,数据包在数据链路层进行分装,生成以太网数据包,并广播给网内的所有主机;
2.同一广播域中的所有主机都会接收到该ARP请求,IP地址不匹配的主机直接丢弃;
3.若IP匹配则主机会响应一个ARP应答,这个应答中包含了所请求的IPv4地址以及对应的MAC地址,并且这个ARP应答通常直接是以单播的形式发给请求方;
4.同时应答方会学习ARP请求中请求方的IPv4地址和对应的MAC地址,并将这种映射关系记录在其ARP缓存表中;
5.最后,ARP应答被请求方接收,将请求到的映射关系记录在其ARP缓存表中。
至此两边主机的ARP缓存表中都有了对方的ARP表项。
3.3 路由协议
目的:在不同子网间进行数据传输
首先通过IP协议来判断两台主机是否在同一个子网中,如果在同一个子网,就通过ARP协议查询对应的MAC地址,然后以广播的形式向该子网内的主机发送数据包;如果不在同一个子网,以太网会将该数据包转发给本子网的网关进行路由。网关是互联网上子网与子网之间的桥梁,所以网关会进行多次转发,最终将该数据包转发到目标IP所在的子网中,然后再通过ARP获取目标机MAC,最终也是通过广播形式将数据包发送给接收方。而完成这个路由协议的物理设备就是路由器,路由器扮演着交通枢纽的角色,它会根据信道情况,选择并设定路由,以最佳路径来转发数据包。
四.传输层
主要工作:定义端口,标识应用程序身份,实现端口到端口的通信,TCP协议可以保证数据传输的可靠性。
链路层定义了主机的身份,即MAC地址,而网络层定义了IP地址,明确了主机所在的网段,有了这两个地址,数据包就从可以从一个主机发送到另一台主机。但实际上数据包是从一个主机的某个应用程序发出,然后由对方主机的应用程序接收。而每台电脑都有可能同时运行着很多个应用程序,所以当数据包被发送到主机上以后,是无法确定哪个应用程序要接收这个包。因此传输层引入了UDP协议来解决这个问题,为了给每个应用程序标识身份。
4.1 UDP协议
UDP协议定义了端口,同一个主机上的每个应用程序都需要指定唯一的端口号,并且规定网络中传输的数据包必须加上端口信息,当数据包到达主机以后,就可以根据端口号找到对应的应用程序了。
UDP协议比较简单,实现容易,但它没有确认机制,数据包一旦发出,无法知道对方是否收到,因此可靠性较差。UDP 协议不面向连接,也不保证传输的可靠性。
4.2 TCP协议
TCP即传输控制协议,是一种面向连接的、可靠的、基于字节流的通信协议。简单来说TCP就是有确认机制的UDP协议,每发出一个数据包都要求确认,如果有一个数据包丢失,就收不到确认,发送方就必须重发这个数据包。为了保证传输的可靠性,TCP协议在UDP基础之上建立了三次对话的确认机制,即在正式收发数据前,必须和对方建立可靠的连接。TCP数据包和UDP一样,都是由首部和数据两部分组成,唯一不同的是,TCP数据包没有长度限制,理论上可以无限长,但是为了保证网络的效率,通常TCP数据包的长度不会超过IP数据包的长度,以确保单个TCP数据包不必再分割。
序号:指出段中的数据部分在发送方数据流中的位置。
确认号:指出接收方希望收到对方下次发送的数据的第一个字节的序号。
TCP段首部的定长部分为20个字节,即5个单位的长度。
URG位:紧急标志,和紧急指针配合使用,当其为1时表示,此报文要尽快传送。
ACK位:确认标志,和确认号字段配合使用,当ACK位置1时,确认号字段有效。
PSH位:为推送标志,置1时,发送方将立即发送缓冲区中的数据。
RST位:复位标志,置1时,表明有严重差错,必须释放连接。
SYN位: 同步标志,置1时,表示请求建立连接。
FIN位:终止标志,置1时,表明数据已经发送完,请求释放连接。
窗口大小:32bit,用于向对方通告当前本机的接受缓冲区的大小。
校验和字段长度:16bit,校验范围包括段首部、数据以及伪首部。
4.3 TCP建立连接---三次握手
TCP是面向连接的,无论哪一方向另一方发送数据之前,都必须先在双方之间建立一条连接。在TCP/IP协议中,TCP协议提供可靠的连接服务,连接是通过三次握手进行初始化的。三次握手的目的是同步连接双方的***和确认号并交换 TCP窗口大小信息。
第一次握手: 建立连接。客户端发送连接请求报文段,将SYN位置为1,Sequence Number为x;然后,客户端进入SYN_SEND状态,等待服务器的确认;
第二次握手: 服务器收到SYN报文段。服务器收到客户端的SYN报文段,需要对这个SYN报文段进行确认,设置Acknowledgment Number为x+1(Sequence Number+1);同时,自己自己还要发送SYN请求信息,将SYN位置为1,Sequence Number为y;服务器端将上述所有信息放到一个报文段(即SYN+ACK报文段)中,一并发送给客户端,此时服务器进入SYN_RECV状态;
第三次握手: 客户端收到服务器的SYN+ACK报文段。然后将Acknowledgment Number设置为y+1,向服务器发送ACK报文段,这个报文段发送完毕以后,客户端和服务器端都进入ESTABLISHED状态,完成TCP三次握手。
为什么要三次握手
为了防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误。
例如:client发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段,但server收到此失效的连接请求报文段后,就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段,同意建立连接。假设不采用“三次握手”,那么只要server发出确认,新的连接就建立了。由于现在client并没有发出建立连接的请求,因此不会理睬server的确认,也不会向server发送数据。但server却以为新的运输连接已经建立,并一直等待client发来数据。这样,server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况,client不会向server的确认发出确认。server由于收不到确认,就知道client并没有要求建立连接。
4.4 TCP断开连接---四次挥手
第一次挥手: 主机1(可以使客户端,也可以是服务器端),设置Seq Number,向主机2发送一个FIN报文段;此时,主机1进入FIN_WAIT_1状态;这表示主机1没有数据要发送给主机2了;
第二次挥手: 主机2收到了主机1发送的FIN报文段,向主机1回一个ACK报文段,Acknowledgment Number为Sequence Number加1;主机1进入FIN_WAIT_2状态;主机2告诉主机1,我“同意”你的关闭请求;
第三次挥手: 主机2向主机1发送FIN报文段,请求关闭连接,同时主机2进入LAST_ACK状态;
第四次挥手: 主机1收到主机2发送的FIN报文段,向主机2发送ACK报文段,然后主机1进入TIME_WAIT状态;主机2收到主机1的ACK报文段以后,就关闭连接;此时,主机1等待2MSL后依然没有收到回复,则证明Server端已正常关闭,那好,主机1也可以关闭连接了。
MSL:报文段最大生存时间,它是任何报文段被丢弃前在网络内的最长时间。
为什么四次挥手
TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式,这就意味着,当主机1发出FIN报文段时,只是表示主机1已经没有数据要发送了,主机1告诉主机2,它的数据已经全部发送完毕了;但是,这个时候主机1还是可以接受来自主机2的数据;当主机2返回ACK报文段时,表示它已经知道主机1没有数据发送了,但是主机2还是可以发送数据到主机1的;当主机2也发送了FIN报文段时,这个时候就表示主机2也没有数据要发送了,就会告诉主机1,我也没有数据要发送了,之后彼此就会愉快的中断这次TCP连接。
为何等待2MSL
保证TCP协议的全双工连接能够可靠关闭
保证这次连接的重复数据段从网络中消失
第一点:如果主机1直接CLOSED了,那么由于IP协议的不可靠性或者是其它网络原因,导致主机2没有收到主机1最后回复的ACK。那么主机2就会在超时之后继续发送FIN,此时由于主机1已经CLOSED了,就找不到与重发的FIN对应的连接。所以,主机1不是直接进入CLOSED,而是要保持TIME_WAIT,当再次收到FIN的时候,能够保证对方收到ACK,最后正确的关闭连接。
第二点:如果主机1直接CLOSED,然后又再向主机2发起一个新连接,我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题,但是还是有特殊情况出现:假设新连接和已经关闭的老连接端口号是一样的,如果前一次连接的某些数据仍然滞留在网络中,这些延迟数据在建立新连接之后才到达主机2,由于新连接和老连接的端口号是一样的,TCP协议就认为那个延迟的数据是属于新连接的,这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME_WAIT状态等待2倍MSL,这样可以保证本次连接的所有数据都从网络中消失。
4、应用层
主要工作:定义数据格式并按照对应的格式解读数据。
理论上讲,有了以上三层协议的支持,数据已经可以从一个主机上的应用程序传输到另一台主机的应用程序了,但此时传过来的数据是字节流,不能很好的被程序识别,操作性差,因此,应用层定义了各种各样的协议来规范数据格式,常见的有http,ftp,smtp等,在请求Header中,分别定义了请求数据格式Accept和响应数据格式Content-Type,有了这个规范以后,当对方接收到请求以后就知道该用什么格式来解析,然后对请求进行处理,最后按照请求方要求的格式将数据返回,请求端接收到响应后,就按照规定的格式进行解读。
参考文献:
1.关于TCP/IP,必须知道的十个知识点 https://www.toutiao.com/i6570218601117123080/
2.网络基础---TCP连接 https://blog.****.net/u010670619/article/details/50998260
3.TCP/IP协议简述 https://blog.****.net/weixin_38885808/article/details/81154983
4.一文搞懂什么是TCP/IP协议 https://blog.****.net/petterp/article/details/102779131
6.TCP/IP协议 https://baike.baidu.com/item/TCP/IP%E5%8D%8F%E8%AE%AE/212915