TCP：面向连接的服务，可靠的进程到进程的通信协议。（因为TCP里面封装了端口号，端口号就意味着一个服务，进程）；应用场景：如：文件传输；HTTP应用层协议

UDP：无连接服务、不可靠的传输协议；
应用场景：广播；早期的QQ，视频传输等，

• ACK：标识确认序号是否有效；TCP协议规定，只有ACK=1时有效，也规定连接建立后所有发送报文的 ACK 必须为1.
• SYN：请求建立连接，含有 SYN 标识的报文称为同步报文段。当 SYN = 1,ACK = 1时则表示对方同意连接。
• FIN：当FIN = 1时，表明结束报文段的发送方不再发送数据，请求释放单向连接。
• SYN-SENT：同步已发送状态
• SYN-RCVD：同步收到
• 序列号：TCP 将每个字节的数据都进行了编号, 即为序列号
• 确认序列号：每一个 ACK 都带有对应的确认序列号，意思是告诉发送者，我已经收到了哪些数据；下一次你要从哪里开始发。
• FIN-WAIT-1：终止等待1；
• FIN-WAIT-2：终止等待2；
• TIME-WAIT状态：TCP 协议规定，主动关闭连接的一方要处于 TIME-WAIT 状态，等待 2*MSL 的时候后才能回到 CLOSE 状态。
• LAST-ACK：最后确认状态；
• CLOSE-WAIT：关闭等待状态；

三次握手：

1. 客户端发送连接请求报文给服务端，SYN = 1,seq = x（初始序列号）,发送后客户端进入SYN - SENT（同步发送）状态。TCP规定, SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。
2. 服务器收到请求报文后，若同意则发出确认报文。确认报文 ACK = 1,SYN = 1,确认序号为x+1,同时初始化序列号 seq=y,之后服务器进入 SYN-RCVD（同步收到）状态。
3. 客户端接收到报文后,发送确认报文，其中ACK=1,确认序列号：ack=y+1。自己的序列号：seq:x+1 发送完客户端进入ESTABLISHED状态，服务端接收到报文后，进入ESTABLISHED状态。到此，连接建立完成。

？问：为什么不是2次握手？

为了实现可靠数据传输， TCP 协议的通信双方， 都必须维护一个序列号， 以标识发送出去的数据包中， 哪些是已经被对方收到的。 三次握手的过程即是通信双方相互告知序列号起始值， 并确认对方已经收到了序列号起始值的必经步骤
如果只是两次握手， 至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到确认

四次挥手

1. 客户端进程发出断开连接报文，并停止发送数据。其中：FIN = 1,序列号为 seq = u (等于之前已经传送的数据序号+1)，此时客户端进去 FIN - WAIT-1（终止等待1）状态。TCP 规定，FIN 报文段即使不带数据，也要消耗一个序号。

2. 服务器收到连接释放报文，发出确认报文，ACK =1,确认序号ack=u+1,自己序列号：seq=v。服务器->CLOSE-WAIT(关闭等待)状态。这个时间段，客户端没有数据发送了，若服务器还有数据，客户端依然要接受，这个状态就是CLOSE-WAIT的时间段。

   客户端收到确认请求后，客户端进入FIN-WAIT2（终止等待2）状态，等待服务器发送释放报文（在这之前还需要接受服务器发送的最后数据）。

3. 服务器发送完数据后，最后向客户端发送释放报文，FIN = 1,确认序号ack=u+1,由于处在半关闭状态，服务器可能又发送了一些数据，假定序列号：seq=w,此时，服务器进入LAST-ACK（最后确认）状态。

4. 客户端收到服务器的连接释放报文后，发出确认，ACK= 1，ack = w+1,seq=u+1.此时，客户端进入TIME-WAIT（时间等待状态）。注意此时TCP连接还没有释放，必须经过2MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入Close状态。服务器只有收到客户端的确认就会立刻close,而客户端需要等待2MSL后才close.服务器更早close.

？ 为什么最后客户端要等待2*MSL的时间呢？

• MSL（Maximum Segment Lifetime），TCP允许不同的实现设置不不同的值。Win10是2min.

• 第一，保证客户端发送的最后的ACK报文能到达服务器，若这个ACK丢失，服务器若收不到确认报文会重新发送FIN请求，而客户端收到重传的报文，再次发送确认报文，重启2*MSL计时器。

？为什么建立连接是3次，关闭却要4次？

• 建立连接的时候，服务器收到连接请求的 SYN 报文后，把 ACK 和 SYN 放在一个报文里发给客户端。

• 关闭连接的时候，服务器收到 FIN 报文时，仅仅是客户端不再发送数据了，而自己可能还有数据未发送，故多了一步，先确认回复同意关闭请求，进入close-wait状态，发送完数据再发送FIN 释放报文。

保障可靠性的机制：

- 检验和

- 序列号

- 确认应答机制（ACK 机制）

TCP 将每个字节的数据进行了编号，即为序列号。每一个 ACK 都带有对应的确认序列号，意思是告诉发送者，我已经收到了哪些数据；下一次你要从哪里开始发。

比如：客户端向服务器发送了1005字节的数据，服务器返回给客户端的确认序号是1003，那么说明服务器只收到了1-1002的数据。1003,1004,1005没收到，此时客户端就会从1003开始重发。

- 超时重传

如：客户端发送数据给服务端后，可能因为网络拥堵等原因，数据无法到达（也可能是服务器传送的ACK丢失了），如果客户端在一个特定的时间间隔内没有收到服务器发来的确认应答，就会进行重发。

这种情况下服务器会收到很多重复数据，那么TCP 协议需要识别出哪些包是重复的，通过序列号进行去重。

超时时间确定？

TCP为了保证任何环境下都能保持较高性能的通信，因此会动态计算这个最大的超时时间；

Linux和Windows，超过500ms为一个单位进行控制，再次发送会是500ms的整数倍。如第2次发送为2*500ms.

- 连接管理

- 流量控制

- 拥塞控制

提高性能的机制：

- 滑动窗口

• 窗口大小指的是无需等待确认应答就可以继续发送数据的最大值；
• 如果窗口最大为4000个字节（四个段），发送前4个段的时候不需要等待任何ACK，之后收到第一个ACK 确认应答后，窗口向后移动，继续发送第5,6,7，8段的数据。 因为这个窗口不断向后滑动，所以叫做滑动窗口

- 快速重传

- 延迟应答

- 捎带应答

定时器：

- 超时定时器

- 保活定时器

- TIME_WAIT定时器

参考：

https://blog.csdn.net/sinat_36629696/article/details/80740678?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522162184417316780255255630%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fall.%2522%257D&request_id=162184417316780255255630&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~first_rank_v2~rank_v29-1-80740678.pc_search_result_cache&utm_term=TCP&spm=1018.2226.3001.4187