TCP协议

TCP协议

TCP：传输控制协议，是TCP/IP协议栈中传输层的典型协议。TCP协议的特点是面向连接，可靠传输，面向字节流。

协议字段

(1)16位源端口、16位目的端口：描述数据从哪个进程来，传送到哪个进程去
(2)32位序号、32位确认序号：进行tcp协议栈中的包序管理
(3)4位首部长度：长度单位是4个字节：20~15*4个字节
(4)6位保留
(5)6位标志位：URG/ACK/PSH/RST/SYN/FIN
(6)16位窗口大小：接收端期望接收的字节数。解决流量控制的问题
(7)16位校验和：由发送端计算和存储，由接收端校验。解决数据正确性问题
(8)16位紧急指针
(9)40字节选项数据

特性的实现：

1. 面向连接：三次握手，四次挥手

（1）连接建立的三次握手的流程：

三次握手建立连接的过程：

• ①客户端发送SYN，表明向服务器建立连接；
• ②服务端返回ACK作为确认，同时返回SYN作为应答；
• ③客户端发送ACK确认收到回复。

状态说明：

• 服务端等待客户端建立连接时处于LISTEN监听状态；
• 客户端主动打开请求，发送SYN时处于SYN_SENT状态；
• 服务端收到SYN处于SYN_REVD状态；
• 客户端收到SYN和ACK，并回复ACK时，处于ESTABLISHED状态等待发送报文;
• 服务端收到ACK确认后，也处于ESTABLISHED状态等待发送报文;

（2）关闭连接的四次挥手：

关闭连接的过程：

• 主动关闭的一方发送FIN，表示要单方面关闭数据的传输；
• 服务端收到FIN后，发送一个ACK作为确认；
• 等服务器数据传输完毕，也发送一个FIN标识，表示关闭这个方向的数据传输；
• 客户端回复ACK以确认回复；

状态说明：

• 客户端发送FIN后，处于FIN_WAIT1状态；

• 服务端收到FIN并发送ACK时，处于CLOSE_WAIT状态；

• 客户端收到ACK确认后，处于FIN_WAIT2状态；

• 服务端发送FIN后，处于LAST_ACK状态；

• 客户端收到FIN后发送ACK，处于TIME_WAIT状态；

• 服务端收到ACK后，处于CLOSED状态。
  三次握手一四次挥手中的相关问题：https://blog.csdn.net/sinat_38606329/article/details/101536915
  

  TCP中通信双方同时打开连接
  两个应用程序同时执行主动打开，称为“同时打开“。这种情况极少发生，两端同时发送SYN，同时进入SYN_SENT状态。打开一条连接而不是两条。要进行四次报文交换过程，“四次握手”。
  
  通信双方同时主动关闭连接：
  双方同时执行主动关闭，进行四次报文交换，状态和正常关闭不一样。
  
  TCP协议中的保活机制：
  通信双方长时间没有数据往来，则向对方发送保活探测数据包，要求对方进行响应。若得到对方的相应，则表示连接正常。若一直未收到对方的相应，则表示连接断开，将socket的状态置为CLOSE_WAIT状态。当处于该状态时，程序中的反映是：recv()函数返回0；send()函数会触发SIGPIPE异常。
  默认7200s无通信，则要发送保活探测数据包，每隔75s发送一次，连续发送9次。

2.可靠传输

TCP保证可靠传输：面向连接（前提）、超时重传机制、确认应答机制、协议中的序号/确认序号、协议中的校验和
TCP协议为了实现可靠传输就会牺牲部分性能，那么如何避免丢包和提高性能？
避免丢包：快速重传机制、使用滑动窗口机制实现流量控制、拥塞控制
提高可靠性：捎带应答机制、延迟应答机制
（1）避免丢包
滑动窗口机制：滑动窗口是两台主机间传送数据时的缓冲区。每台TCP /IP 主机支持两个滑动窗口,一个用于接收数据, 另一个用于发送数据。窗口尺寸表示计算机可能缓冲的数据量大小。TCP为了保证数据传输速率，它需要一次尽可能多的传送数据，但数据一次发送太多出错的可能性也大，因此TCP通过一套机制来动态调整每次数据的发送量，这套机制就是滑动窗口。

• 当两个主机A和B建立TCP连接时，再交换报文的过程中，A将自己的窗口大小发送给B，同样，B也将自己的敞口大小发送给A。
• 当A开始发送数据，由于A知道B的窗口大小，当A发送过来的数据逐渐将缓冲区填满。A 就不能再发了，需等待 B 的确认。
• 这时候缓冲区中的一个报文被进程读取，缓冲区有了一个空位，于是 B 向 A 发送一个 ACK，这个报文中指示目前的窗口大小。
• A 收到 B 发过来的 ACK 消息，并且知道 B 将窗口大小调整，因此他只发送了相应大小的数据并且等待 B 的下一个确认报文。
• 如此反复。。。
  窗口大小的调节：
  对于发送方：窗口大小的调节取决于是否接收到ACK回复。
  对于接收方：窗口大小取决于是否接收到数据，即接收方接收缓冲区的剩余空间。
  ①流量控制：接收方每次接收到数据后，通过确认回复ACK想对端传递窗口大小，限制对方最多能发送的数据量，避免对方发送数据过多导致接收缓冲区满溢后数据丢失。
  ②拥塞控制：
  计算机网络中的带宽、交换结点中的缓存、路由器等等都是网络的资源，他们所能提供的可用资源都是有限的，如果某一时间，对网络中某一资源的需求超过了它的可用部分，网络的性能就会变坏，就是出现拥堵，就是拥塞控制。
  慢启动，快增长。 一开始先不发送大量的数据，需要先探测一下网络的拥塞程度，由小变大的逐渐增加拥塞窗口的大小。当网络发生拥塞时，立即减小窗口大小，重新开始慢启动，快增长。以避免因为网络状态不好导致大量的丢包现象。
  ③快速重传机制：
  在连续的数据发送中，若接收方已收到第二条收据但没有收到第一条数据，认为第一条数据可能丢失，则向发送方发送第一条数据重传的请求，并且通常连续发送三次重传请求。若接收方收到连续三条数据重传请求，则对该条数据进行重传。
  连续发送三次重传请求的目的：因为网络迟延而导致数据未收到，避免在这种情况下的数据重复传输。
  （2）提高性能
  ①捎带应答机制：若接收方在收到数据后，正好也要想对端发送数据，则将确认回复和要发送的数据合成一个数据包发送过去。
  ②延迟应答机制：收到数据后，并不立即发送确认回复，延迟等待一段时间后再发送。
  原因：进行确认回复后，会是的窗口变小，网络吞吐量变低，传输速率降。
  延迟的目的是在这段时间内尽可能的保证窗口大小，让用户有可能将数据取出。延迟等待的时间不会太长，一般不会超过500ms。

3.面向字节流：

TCP协议调用send()接口发送数据，是将数据放到发送缓冲区中，操作系统选择合适的时间取出MSS大小的数据，将数据发送出去。Recv/send所接收或发送的数据没有大小限制，传输灵活。
Tcp在传输时会存在粘包问题， 即多条数据在发送或接收缓冲区中粘连成一条数据。产生粘包的本质原因是TCP协议对数据不敏感。
解决方案： 在应用层进行数据边界管理
①以特殊字符间隔；②数据定长；③在应用协议头中定义数据长度。