传输层协议笔记(TCP、UDP)

传输层协议笔记

TCP和UDP差别

端口

​ 由传输层的主要作用：提供主机之间不同进程之间的通信可知，在网络层提供了IP地址之后我们需要定位到具体的某一个进程，而定位到具体进程的方式就是通过端口。

主机 — IP地址

主机网络进程 — 端口

套接字(socket) — IP地址 + 端口

端口实际上是一个数字，占16位，端口范围在：0~65535

UDP头部

UDP长度其实是标识UDP数据报文的长度有多长，而UDP校验和是UDP数据附加的标识，通过这个校验和就可以判断数据在传输过程是否有发生差错，也即校验和是判断数据准确性的重要字段。

TCP头部

注意上图中前五行是固定20字节。

• TCP协议-序号

  占4个字节[0, 4294967295]

  TCP数据就是字节流，每一个字节都有唯一的序号

  起始序号在建立TCP连接时设置

  序号表示本报文段第一个字节的序号，在TCP数据中肯定不止一个字节，但在该报文中序号表示的是第一个字节的序号

• TCP协议-确认号

  和序号一致-占4个字节

  期待收到对方下一个报文的第一个数据字节序号

  如确认号为n，即代表序号n-1为止的所有数据均已正确收到

• TCP协议-控制位

  占6位

  

• TCP协议-窗口

  占2个字节[0, 65535]

  窗口指明允许对方发送的数据量

  数据缓冲空间有限，不能无限缓存数据

差异

协议复杂度不同

​ 由上述所见，TCP协议的头部较UDP而言是复杂许多的，因为

• TCP提供的是可靠的，有连接服务
• UDP提供的是不可靠的，无连接的服务

而为了达到可靠、有连接，TCP需要做额外很多工作来保证这一点。而UDP协议只管发送，什么都不保证。TCP就好比打电话，需要拨通后进行交流，然后交流结束后挂断电话。UDP就好比写信，我只管写信和发送，对方收不收得到我是无从得知的。

有连接：

• 建立连接
• 通过连接进行通信
• 释放连接

可靠：

• 可靠传输：无差错、不丢失、不重复
• 按序到达：数据有序

应用场景

TCP三次握手

• 第一次握手

  

  在进行第一次握手时，客户端会主动发送一个同步位SYN=1和一个序号seq=x给服务端，在接收到这个第一次发送的连接请求报文前客户端是处于监听阶段的。

• 第二次握手

  在接收到客户端发送的连接请求报文后，服务端会开始进行第二次握手

  

  在第二次握手中，SYN=1仍是代表这个报文为连接请求报文，ACK=1表示确认号是生效的，返回的ack=x+1表示当前序列号为x的这个数据服务端已收到，下一次期望收到的序列号为x+1，并且服务端发送了自己的序列号seq=y。而在客户端发送第一次连接请求报文和接收到服务端的第二次握手之间，客户端是处于同步已发送阶段(SYNC-SENT)。

• 第三次握手

  

  在客户端接收到服务端发送的第二次连接请求报文后，会开始进行第三次握手，ACK=1仍代表该确认号生效，seq=x+1回应服务端发送的ack=x+1，即服务端期望收到的下一次序列号，ack=y+1表示客户端已收到序列号为y的数据，并期望收到的下一次数据序号为y+1

  在完成三次握手之后，双方就已经建立连接并开始数据传输

  

  需要注意的是，客户端和服务端进入ESTABLISHED阶段时间是不一样的，客户端在发送了第三次握手之后就已经进入了该状态，而服务端需接收到该连接请求报文后才进入。

三次握手的异常情况

• 

  当客户端发送的第一次握手报文丢失时，客户端是无法感知报文是否到达服务端的，但服务端久久未回应，客户端就认为第一次报文已丢失，并第二次发送第一次握手的报文，而有可能这个第一次报文并不是丢失而是只是滞留了

  

  在发送了两次第一次握手报文之后，服务端实际上是会对两次握手都进行回应的。 而如果只有两次握手的话，此时客户端和服务端就因为异常情况分别建立了两个TCP连接，从资源的角度看待，这样就导致了很多不必要的资源的损耗，因为另一个连接是不必要的；而如果编程不严谨，分别对这两个连接都进行通信的话，很有可能导致程序的错误以及数据的错误，已经影响了应用的正常工作了，后果就更严重了。

  

  所以就需要第三次握手，客户端可以选择丢弃其中一个，保证只有一个连接。如此一来三次握手就能保证双方所建立的连接都是可靠的且为无差错的。

  

TCP四次握手

这里需要明确一个控制位，FIN — finish：终止位，在FIN = 1时表示释放连接

其实理解了三次握手的流程后，看发送报文的信息八九不离十也能看出这四次握手是干了什么，但是需要注意的点是在主动中断连接方发出第一次挥手释放连接报文时，被动中断连接方的第二次挥手就只是正常的确认收到报文并没有发送释放连接的控制位FIN = 1，原因是在这个时候可能被动中断连接方数据并没有发送完，所以在第二次挥手和第三次挥手期间，被动中断方处于CLOSE-WAIT关闭等待阶段，这个阶段被动中断方还是可以继续发送数据的。而在发送完数据之后，被动中断方就会发送释放连接请求报文，即第三次挥手，接着主动中断方在收到后就会发出确认收到连接请求包，完成四次挥手，连接中断。而在被动中断方发出第三次挥手到接收到确认报文时是处于LAST-ACK最后确认阶段，这个阶段被动中断方就只是等待接收主动中断方发出的确认报文，即确认第三次挥手的报文对方已经正确收到。

TIME-WAIT状态

​ TIME-WAIT状态指的是在第四次挥手后，主动中断方所处的状态，在这个状态下，主动方尚未完全关闭TCP连接，端口不可复用。而这个状态会持续多久呢，这边引出了个新的概念：

• MSL(Max Segment Lifetime):最长报文寿命

  RFC 793标准建议设置为2min

而TIME-WAIT状态所持续的时间就是为2MSL

那么为什么要有TIME-WAIT状态并设置为2MSL呢？

• 最后一个报文没有确认
• 确认最后一个ACK报文一定能到达对方
• 2MSL时间内，如果没有到达对方，那么对方会重新进行第三次挥手，确保连接正常释放

那么怎么确定最后一个ACK报文有没有到达对方呢？在发送完最后一个ACK报文后，如果被动中断方没有接收到该报文，会重新发送第三次挥手，这就表明其ACK报文并没有成功到达对方。

以上只是第一个原因，确保连接正常释放，还有第二个原因，确保当前连接所有报文已过期，因为第四次挥手的报文是当前连接的最后一个报文，如果最后一个报文都过期了得话，那么当前连接内得所有报文都已过期了，所以就通过等待2MSL确保当前网络上所有报文都已经过期。如此一来，即使在网络中有一些报文滞留了很久也不会对双方造成影响。