一. TCP基础原理

1. TCP头的格式 和 segment

1.1. TCP头的格式

TCP的包是没有IP地址的，那是IP层上的事。但是有源端口和目标端口。一个TCP连接需要四个元组来表示是同一个连接（src_ip, src_port, dst_ip, dst_port）准确说是五元组，还有一个是协议。

头中四个重要的参数：

参数	说明
Sequence Number	包的序号，用来解决网络包乱序（reordering）问题。
Acknowledgement Number	ACK——用于确认收到，用来解决不丢包的问题。
Window	又叫Advertised-Window，也就是著名的滑动窗口（Sliding Window），用于解决流控的
TCP Flag	包的类型，主要是用于操控TCP的状态机的

 

1.2. segment

TCP网络协议中：第二层上的数据，我们叫Frame，在第三层上的数据叫Packet，第四层的数据叫Segment。

发送数据时

我们程序的数据首先会打到TCP的Segment中，然后TCP的Segment会打到IP的Packet中，然后再打到以太网Ethernet的Frame中，传到对端后，各个层解析自己的协议，然后把数据交给更高层的协议处理。

 
 

2. TCP的状态机与连接与关闭连接

先来一张TCP状态机的状态转换图，表示了client和server端状态的转换流程。

图中的11种状态

状态	解释
listen	server等待client端发来的连接请求
syn_sent	client发送一个syn报文，代表应用程序执行了主动打开的操作，并等待对端回应以此完成连接的建立
syn_recv	server端收到了client的syn报文，并发送了SYN/ACK报文（这个报文同时设置了SYN和ACK位），等待client发送ACK，以此完成建立进入established
fin_wait1	应用程序关闭了连接。client发送一个fin报文，用来中断连接并等待对端发来的ACK。
fin_wait2	fin_wait1的client端已经收到了server发来的ACK（半关闭）
closing	之前处在FIN_WAIT1状态的client正在等待对端发送ACK，但却收到了FIN。这表示server端也正在尝试执行一个主动关闭。（换句话说，这两个TCP节点几乎在同一时刻发送了FIN报文。即同时关闭）
time_wait	client完成主动关闭后，收到了fin报文（server端执行了一个被动关闭）。此时client将在time_wait阶段中等待一段时间，为了确保tcp连接可靠的终止，同时确保任何老的报文在重新建立连接之前超时，当固定段超时后，连接就关闭了，相关内核资源得到释放。
close_wait	server端收到（处于fin_wait1的client发送）fin报文后，将状态设置为close_wait状态。
last_ack	应用程序被动关闭，处于close_wait状态的server端发送一个fin报文给client并等待确认。收到ack报文时，连接关闭，相关内核资源释放
closed	关闭状态

 
 

3. 三次握手与四次挥手

先了解几个概念：

1. 双工的概念：TCP是全双工的
   全双工：client在给server发送信息的同时server也可以client发送信息；
   半双工：server可以给client发送信息或相反，但是client和server不能同时发。
    
2. 发送syn表示和对方建立一个连接，ack表示收到对方的syn后做出回应，是两个操作。

 

3.1. 建立连接：三次握手

对于三次握手建立连接，有一个主要动作是初始化Sequence Number的初始值，client和server要互相通知自己的SN初始值是多少，此过程称为 SYN（Synchronize Sequence Numbers）。 以便之后数据传递过程中不出现乱序的问题。

• 第一次：建立连接。client发送SYN报文（其中位置设置为1，SN设置为J），并进入syn_send状态，等待服务器确认
• 第二次：server收到SYN报文后，ack：进行报文确认（设置Acknowledgment Number为J+1），syn：同时发送自己的SYN报文（位置设置为1，SN设置为k），server置为syn_recv。
• 第三次：client收到SYN+ACK报文段后，设置AN（k+1），并发送SYN，之后client和server都进入establish状态。

 

3.2. 关闭连接：四次挥手

server端或client端，都可以是发起者

• 第一次挥手：client（可以是client或server），发送fin（设置sequence Number 和 Acknowledgment Number）报文段给server，client进入fin_wait1状态，表示client没有数据要发送给server端了。
• 第二次挥手：sever收到了client的fin报文后，回复client一个ack（AN（=SN+1））报文，client收到后，状态为fin_wait2。此时告诉client，server接收到了它的请求且server要做一些关闭自己前的清理工作。
• 第三次挥手：server向client发送fin（清理工作已经做完，请求关闭连接）报文，并将自己设置为close_wait.
• 第四次挥手：client收到server的fin报文，向server发送ack报文，然后client进入time_wait状态。server收到ack，就关闭连接，此时，client等待2MEL后依然没有收到回复，则说明server已正常关闭，此时client也关闭连接。

 

3.3. TCP四次挥手过程中，为什么需要等待2MSL,才进入CLOSED关闭状态

2MSL，two Maximum Segment Lifetime，即两个最大段生命周期。

假设主动发起挥手的是client，那么需要2MSL的原因是：

1. 为了保证client发送的ack报文server端能收到：
   假设ack报文段丢失，server端就收不到报文。server端因报文超时，重传fin+ack（二、三次挥手）给client确认，此时client就能在2MSL（超时 + 1MSL）收到重传的fin+ack报文段，然后发送ack给server，重新开启2MSL计时。
    
2. 防止已失效的连接请求报文段出现在本连接中：
   client发完最后一个ack报文段后，再经过2MSL就可以使本连接持续的时间内，所产生的所有报文段都消失，这样就可以使下一个连接中不会出现这种旧的连接报文段

 
 

二. TCP连接相关问题

1. 建立连接时SYN超时

假设server端收到client发送的syn，并回复了ack后，client掉线了，server没有再接收到client的ack，此时连接就处于一个中间状态。于是server再一定时间内没有收到ack时就重发syn-ack。
linux下，默认重试为5次，分别为：1、2、4、8、16共31秒，第五次后再等待超过32s后（client和server都知道第五次也失效了），还没有接收到client的ack，就会断开这个连接。共63秒。

 

2. SYN Flood攻击与半连接队列ing

SYN Flood攻击——给服务器发了一个SYN后，就下线了，于是服务器需要默认等63s才会断开连接，这样，攻击者就可以把服务器的syn连接的队列耗尽，让正常的连接请求不能处理。

linux下给了一个叫tcp_syncookies的参数来应对

当SYN队列满了后，TCP会通过源地址端口、目标地址端口和时间戳创建出一个特别的Sequence Number发回去（又叫cookie），如果是攻击者则不会有响应，如果是正常连接，则会把这个 SYN Cookie发回来，然后服务端可以通过cookie建连接（即使你不在SYN队列中）。

 

3. 关闭连接时TIME_WAIT状态过多的危害

3.1. 会出现的问题

1. time_wait 状态结束前，该socket所占用的端口将一直无法释放。在高并发（没秒几万qps）且采用短连接方式的交互系统，在运行一段时间后，系统中就会出现大量的time_wait状态，当time_wait将系统中可用的端口都占用完了，就出现无法向server端创建新的socket连接的情况，此时系统几乎停转，任何连接都不能建立。
2. 大量的time_wait也会占用一定的fd、内存和cpu资源，当然这个量比较小，不是主要危害。

 

3.2. 优化time_wait过多的方式

a. 调整系统内核参数

修改/etc/sysctl.conf文件，一般涉及下面的几个参数：

net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；
net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。
net.ipv4.tcp_fin_timeout =  修改系统默认的 TIMEOUT 时间
net.ipv4.tcp_max_tw_buckets = 5000 表示系统同时保持TIME_WAIT套接字的最大数量，(默认是18000). 当TIME_WAIT连接数量达到给定的值时，所有的TIME_WAIT连接会被立刻清除，并打印警告信息。但这种粗暴的清理掉所有的连接，意味着有些连接并没有成功等待2MSL，就会造成通讯异常。一般不建议调整

其他优化：

net.ipv4.ip_local_port_range = 1024 65535 增加可用端口范围，让系统拥有的更多的端口来建立链接，这里有个问题需要注意，对于这个设置系统就会从1025~65535这个范围内随机分配端口来用于连接，如果我们服务的使用端口比如8080刚好在这个范围之内，在升级服务期间，可能会出现8080端口被其他随机分配的链接给占用掉，这个原因也是文章开头提到的端口被占用的另一个原因
net.ipv4.ip_local_reserved_ports = 7005,8001-8100 针对上面的问题，我们可以设置这个参数来告诉系统给我们预留哪些端口，不可以用于自动分配。

 

b. 使用nginx调整短链接为长链接

简介一下短连接和长连接

短连接：连接->传输数据->关闭连接

• HTTP是无状态的，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。
• 也可以这样说：短连接是指SOCKET连接后发送后接收完数据后马上断开连接。
   

长连接：连接->传输数据->保持连接 -> 传输数据-> 。。。->关闭连接。

• 长连接指建立SOCKET连接后不管是否使用都保持连接，但安全性较差。

长连接比短连接从根本上减少了关闭连接的次数，减少了TIME_WAIT状态的产生数量，在高并发的系统中，这种方式的改动非常有效果，可以明显减少系统TIME_WAIT的数量。

 

从client到nginx的长连接

默认情况下，nginx已经自动开启了对client连接的keep alive支持。
一般场景可以直接使用，但是对于一些比较特殊的场景，还是有必要调整个别参数（keepalive_timeout和keepalive_requests）。

http {
    keepalive_timeout  120s 120s;
    keepalive_requests 10000;
}

keepalive_timeout：
第一个参数：设置keep-alive客户端连接在服务器端保持开启的超时值（默认75s）；
第二个参数：可选、在响应的header域中设置一个值“Keep-Alive: timeout=time”；通常可以不用设置；


keepalive_requests：
一个keep alive建立之后，nginx就会为这个连接设置一个计数器，记录这个keep alive的长连接上已经接收并处理的客户端#请求的数量#。
如果达到这个参数设置的最大值时，则nginx会强行关闭这个长连接，逼迫客户端不得不重新建立新的长连接。

默认值100凑合够用：
QPS=10000时，客户端每秒发送10000个请求(通常建立有多个长连接)，每个连接只能最多跑100次请求，意味着平均每秒钟就会有100个长连接因此被nginx关闭。
同样意味着为了保持QPS，客户端不得不每秒中重新新建100个连接。
因此，就会发现有大量的TIME_WAIT的socket连接(即使此时keep alive已经在client和nginx之间生效)。
因此对于QPS较高的场景，非常有必要加大这个参数，以避免出现大量连接被生成再抛弃的情况，减少TIME_WAIT。

 

从nginx和server的长连接

upstream http_backend {
 server 127.0.0.1:8080;

 keepalive 1000;//设置nginx到upstream服务器的空闲keepalive连接的最大数量
}

server {
 ...

location /http/ {
 proxy_pass http://http_backend;
 proxy_http_version 1.1;//开启长链接
 proxy_set_header Connection "";
 ...
 }
}

proxy_set_header Connection "";
清理从client过来的http header，因为即使是client和nginx之间是短连接，nginx和upstream之间也是可以开启长连接的。这种情况下必须清理来自client请求中的"Connection" header。

但这个地方需要注意如果有一些认证鉴权的cookie或者session信息在head里面，
不建议开启此选项，或者对需要保留的header要保存下来，否则这些信息可能会丢掉从而发不到上游upstream的服务器上。

 
 

三. 数据传输相关

1. TCP的粘包和拆包

TCP中的negal算法：

通信两端有很多小的数据包要发送，虽然传送的数据很少，但是流程一点没少，也需要tcp的各种确认，校验，这样小的数据包如果很多，会造成网络资源很大的浪费。
negal算法做了这样一件事：当来了一个很小的数据包，我不急于发送这个包，而是等来了更多的包，将这些小包组合成大包之后一并发送，提高了网络传输的效率。

TCP是面向流的：

client到server端数据传输过程中，因为TCP面向流数据没有边界，所以TCP会根据缓冲区（例如1024字节为一个缓冲区）进行包的划分。
一个完整的包可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这就是所谓的TCP粘包和拆包问题。

1. 正常的理想情况，两个包恰好满足TCP缓冲区的大小或达到TCP等待时长，分别发送两个包；
2. 粘包：两个包较小，间隔时间短，发生粘包，合并成一个包发送； 拆包：一个包过大，超过缓存区大小，拆分成两个或多个包发送；
3. 拆包和粘包：Packet1过大，进行了拆包处理，而拆出去的一部分又与Packet2进行粘包处理。

 
解决方案：

1. 给每个数据包添加包首部，首部包含数据包的长度，当服务器端获取到指定的包长时才说明获取完整。
2. 指定包的结束标识，这样当我们获取到指定的标识时，说明包获取完整。
3. 在数据包之间设置边界，如添加特殊符号，这样，接收端通过这个边界就可以将不同的数据包拆分开。

 
 

2. 可靠传输及乱序问题-TCP滑动窗口

TCP必需要解决的可靠传输以及包乱序（reordering）的问题，所以，TCP必需要知道网络实际的数据处理带宽或是数据处理速度，这样才不会引起网络拥塞，导致丢包。

见下篇：ing
 

3. TCP的拥塞处理

见下篇：ing

4. 所以：TCP是如何确保数据的可靠性

连接和断开的可靠性（三次握手，四次挥手）、有状态（哪些数据发送了，哪些没发）、可控制（超时重传、流量控制、拥塞控制等）。

1. TCP的连接是基于三次握手，而断开则是基于四次挥手。确保连接和断开的可靠性。
2. 有状态：TCP会记录哪些数据发送了，哪些数据被接收了，哪些没有被接受，并且保证数据包按序到达，保证数据传输不出差错。
3. 可控制：它有数据包校验、ACK应答、超时重传(发送方)、失序数据重传（接收方）、丢弃重复数据、流量控制（滑动窗口）和拥塞控制等机制。