传输层协议—TCP协议

传输层协议—TCP协议

TCP全称为 “传输控制协议(Transmission Control Protocol”). 人如其名, 要对数据的传输进行一个详细的控制;

应用层将数据向下交付给传输层后，其数据的发送和处理由传输层决定，TCP是传输层协议，即数据的发送和处理由TCP协议来决定，因此TCP被称为传输控制协议。

TCP协议段格式

四位首部长度

• 四位首部长度标识报头大小。有时没有选项，标准报头不含选项。因此标准报头大小为20字节。而四位首部长度范围为0000~1111即[0,15]。该范围并不能涵盖报头大小。因此报头大小=4位首部长度*4字节。即tcp报头总长度范围[0,60]，但标准报头占20字节，因此tcp报头总长度范围[20,60]。超出20字节的部分即为选项部分。若此时报头大小为20字节，此时4位首部长度为[0101]。

TCP协议如何根据目的端口号将数据传输给指定进程？

• 在操作系统内以链表的形式对进程pcb做管理外，还会以hash的方式对进程pcb做管理。以端口号为键值对进程pcb进行管理。
• 接收到tcp报文后，根据目的端口号去操作系统中管理进程pcb的hash数据结构中找到对应进程pcb。进程需要维护自己所管理的文件描述符表。进程pcb内有struct file*，该指针指向进程文件描述符表。
• 在进程文件描述符表内能够找到进程所管理的文件。文件内有自己的读写缓冲区。即在传输层中将tcp报头分离后，直接将tcp的有效载荷发送到进程所管理的读写缓冲区。即以读取文件的方式读取到网络数据。

实际上tcp报头底层也是一个结构体，其处理方式和处理udp方式大同小异。

struct tcp_hdr
{
   
uint32_t src_port;
uint32_t dst_port;
uint32_t req;
uint32_t ack_req;
uint32_t header_length;
......
};

• 传输层接收到应用层向下交付的数据后。开辟一块空间，在该空间内创建tcp_hdr结构体，将结构体内的属性填充完整，然后该空间+应用层交付的数据=tcp报文，接着继续向下交付。

32位序列号和32位确认序列号

实际上不止TCP/IP四层模型中存在协议，硬件中也存在协议。

内存和其他外设相连接的线称为IO总线。内存和CPU相连接的线称为系统总线。而设备之间通信必然是通过协议通信。而外设之间通信很少存在不可靠性问题，其中原因包括外设之间距离狠心，指令、数据传输不容易出现异常。而网络通信不是在本地单主机上通信，而是主机之间通信，而主机之间通信的桥梁是网络，在该前提上数据通信就存在可靠性问题。

可靠性问题

网络通信不存在绝对的可靠性，但存在相对的可靠性。

• 双方在通信，历史信息的可靠性建立在收到响应的前提上。例如小蓝法信息给小绿“今天学习了吗？”，这条信息本身不具备可靠性。小绿回复“学了学了好久呢”，即响应了小蓝发送给小绿的历史短信，此时“今天学习了吗？”这条信息才具备可靠性。
• 历史的信息具备可靠性，但最新消息不具备可靠性。小绿回复小蓝“忘了”，该短信在没收到小蓝的回复之前都不具备可靠性。

通过32位序列号和32位确认序列号来直接确保可靠性

该场景没有涉及到超时重传机制，只谈论序号和确认序号的作用

• tcp报头中有序号和确认序号。序号标识发送出去的信息。由于tcp协议是无状态的，因此需要序号标定状态和连续性。当收到报文时，需要去查询报头的序号，然后响应信息中包含确认序号。例如服务器收到客户端发送来的报文序号是10，那么发送回去的响应的确认序号是11，表示11之前的序号的报文接收成功，且确认序号需要要求是连续的。例如客户端发送給服务器三条信息，依次序号是10，11，12，但序号11标定的信息掉包了导致服务器没有收到，因此服务器响应信息的确认序号只能是11。让客户端知道服务器没有收到序号为10之后的报文，触发重传机制重新发送序号为10之后的报文。

• 而实际上客户端和服务器通信不是客户端发送一条请求给服务器，服务器响应一个ack给客户端。而是并发式的相互交流。数据对于接收方而言数据乱序是一种不可靠的表现，要通过序号来对数据进行排序，保证数据的按序到达。即序号和确认序号保证了信息的顺序性和连续性。

• tcp协议是全双工的，因此需要两组序号来保证信息朝向的可靠性。在发送信息的同时给对方确认ack，这样的报文提高了通信的效率。

TCP报头标志位

TCP报文具有类型区别，区别在于其标志位的设置。实际上该标志位底层是位图，若标志位需要被设置，就由0置1。

SYN标志位标识请求报文

在三次次握手中，客户端向服务器发送的请求报文中的YSN标志位就被置为1。

FIN标志位标识断开报文

在四次挥手中客户端向服务器发送挥手请求的报文中FIN标志位就被置为1。

ACK标志位标识确认报文

在网络通信中ACK标识的报文标识确认应答。

PSH标志位标识催促报文

客户端和服务器通信时，可能会存在接收方处理数据不及时导致接收缓冲区满了，发送方无法再次发送数据的情况。

由于TCP是全双工的，通信双方都具备接收缓冲区和发送缓冲区。客户端向服务器发送数据，服务器将受到的数据放到接收缓冲区。服务器上层调用read将数据从接收缓冲区读取到上层进行处理。会存在上层处理数据的速度慢，客户端发送的数据快，导致服务器的接收缓冲区早早满了。此时客户端再发送数据就会造成丢包问题，而维护连接是需要消耗资源的，通信双方不能由于不能发送数据而长期维护连接。

因此客户端可以将PSH标志位由0置1，只将该标识PSH属性的报文发送给服务器，通知催促服务器尽快处理数据，给接收缓冲区腾出空间来接收新的报文。实际上报头的PSH标志位为1的报文都具备催促含义。

URG标志位标识需要紧急处理的数据

数据对于接收方而言，数据乱序本身就是不可靠的表现。因此可以通过序号对报文标记，对序号进行一定策略的排序，保证数据的按序到达。而按序读取数据自然就产生了等待问题。对于某些需要特殊紧急处理的数据而言，按序等待处理就成了问题。因此需要用URG标定报文含有需要紧急处理的数据，即提示对方上层尽快将该数据读取进行处理。

实际上发送数据函数sendto就可以传递相关参数标识发送的报文具有需要紧急处理的含义

手册说明标志位

MSG_OOB
Sends  out-of-band data on sockets that support this notion (e.g., of type SOCK_STREAM); the underlying protocol must
              also support out-of-band data.

• sendto的第四个参数传参MSG_OOB表示所发送的数据需要被紧急处理，即out-of-band（带外数据），带外数据的处理策略与tcp流的完全分开的，属于独立一套数据处理策略。

接收函数recv也可以传参MSG-OOB表示读取需要紧急处理的数据。

16位紧急指针

URG标定报文含有需要紧急处理的数据。16位紧急指针表示需要紧急处理的数据在有效载荷中的偏移量。

而该需要被紧急处理的数据大小只能为1字节，即TCP的紧急指针只能传输1个字节的数据。

RST标志位标识复位，发送给对方表示需要重置连接

• 客户端和服务器双方通信时，先进行三次握手确定连接成功。然后客户端向服务发送数据。三次握手结束后，服务器由于设备原因单方面掉线，服务器重启后不再认定之前的三次握手，即此时服务器单方面认为没有完成连接，而客户端不知道服务器掉线因此单方面认为连接成功。然后客户端向服务器发送数据。服务器收到了客户端的数据，但由于没有与该客户端建立好连接而收到了发送来的数据感到疑惑，因此服务器需要发送一个具有RST标志位的报文给客户端，表示重新与客户端进行三次握手，即重置连接。

16位检验和

16位校验和: 发送端填充, CRC校验，接收端校验不通过, 则认为数据有问题。此处的检验和不光包含TCP首部, 也包含TCP数据部分。

确认应答机制

• 在TCP协议中，实际上通信双方的接收缓冲区和发送缓冲区是以数组的方式进行管理。数组天生具有下标，即TCP报头的序号。而确认序号为序号+1可以理解为以序号为下标之前的数据全部接收完毕，下次发送数据给我以确认序号作为下标为起点往后开始发送。

超时重传机制

发送数据给对方，对方超过一定时间没有响应应答，自身重新发送数据给对方

客户端向服务器发送数据，会有以下两种场景：客户端认为服务器没有收到数据，客户端重新发送数据给服务器。

场景一：客户端向服务器发送数据，数据在服务器收到之前丢包了，即服务器没有收到数据，因此服务器就没有向客户端响应ACK报文。经过一定时间后，客户端触发超时重传机制，重新向服务器发送数据。

场景二：客户端向服务器发送数据，服务器收到了数据，向客户端响应了ACK报文，但ACK报文掉包了，即客户端没有收到服务器发送来的响应，此时客户端会认为服务器没有收到数据，经过一段时间后，客户端会重新向服务器发送数据。

这个场景下服务器就会收到两份相同的报文，收到重复的报文也是不可靠性的一种，因此服务器需要对报文进行去重操作，通过报文的序号进行去重。

• 客户端发送数据，到重新发送数据期间有一个时间间隔。由于这两次发送的数据是相同的，因此这份数据在收到应答之前应该在接收缓冲区中保存。客户端迟迟没有收到应答，超过特定的时间间隔后重新发送数据给服务器。
• 该决定超时重传机制的特定时间间隔不应该是固定的，因为网络通信的时间长短不只由通信双方决定，还由网络决定，网络是变化的波动的，因此可以认定该特定的时间间隔也是变化的波动的。
• Linux中(BSD Unix和Windows也是如此), 超时以500ms为一个单位进行控制, 每次判定超时重发的超时
  时间都是500ms的整数倍。如果重发一次之后, 仍然得不到应答, 等待 2 * 500ms 后再进行重传。如果仍然得不到应答, 等待 4*500ms 进行重传. 依次类推, 以指数形式递增。累计到一定的重传次数, TCP认为网络或者对端主机出现异常, 强制关闭连接。

再谈三次握手四次挥手