hankviv
commented
4 years ago TCP 是面向连接的、可靠的、基于字节流的传输层通信协议。
- 面向连接：一定是「一对一」才能连接，不能像 UDP 协议可以一个主机同时向多个主机发送消息，也就是一对多是无法做到的；
- 可靠的：无论的网络链路中出现了怎样的链路变化，TCP 都可以保证一个报文一定能够到达接收端；
- 字节流：消息是「没有边界」的，所以无论我们消息有多大都可以进行传输。并且消息是「有序的」，当「前一个」消息没有收到的时候，即使它先收到了后面的字节，那么也不能扔给应用层去处理，同时对「重复」的报文会自动丢弃。
面向连接解释： 为了保证可靠性和流量控制，需要双方都维护对应的数据，这些信息的维护，称为连接。
TCP四元组：
源地址+源端口+目标地址+目标端口是TCP的四元，这四个元素就能确定哪个主机的哪个程序和哪个主机的哪个程序建立通讯。
服务端指定某个固定端口进行监听，一个端口只能被一个进程所监听，客户端的请求端口是操作系统自动分配的。
服务端每收到一个请求，就生成一个标记客户端IP和端口的socket fd，用来区分不同客户端。
服务端最大连接数受限于： 1.每个进程的 文件描述符是有限制的，打开一个Socket也是一个文件句柄。 2.每个TCP连接都会占用一定的内存。操作系统的内存是有限的。
TCP通过肯定的确认应答（ACK）实现可靠的数据传输。当发送端 将数据发出之后会等待对端的确认应答。如果有确认应答，说明数据已经成功到达对端。在一定时间内没有等到确认应答，发送端就可以认 为数据已经丢失，并进行重发。
第一个场景是 主机A发送数据包丢失，主机B未收到数据包。
第二个场景是主机A发送数据包成功，主机B收到数据包，但是发送确认应答数据包丢失。
采样 RTT 的波动范围，计算出一个估计的超时时间。由于重传时间是不断变化的，我们称为自适应重传算法。
注：第一次请求由于没有一个有效的往返时间，系统默认RTT为6s。
数据被重发之后若还是收不到确认应答，则进行再次发送。此时， 等待确认应答的时间将会以2倍、4倍的指数函数延长。
达到一定重发次数之后，如果仍没有任何确认应答返回，就会判断为网络或对端主机发生了异常，强制关闭连接。并且通知应用通信异常强行终止。
当收到之前发送的数据 32-36 字节的 ACK 确认应答后，如果发送窗口的大小没有变化，则滑动窗口往右边移动 5 个字节，因为有 5 个字节的数据被应答确认，接下来 52-56 字节又变成了可用窗口，那么后续也就可以发送 52-56 这 5 个字节的数据了。
TCP 通过让接收方指明希望从发送方接收的数据大小（窗口大小）来进行流量控制。
如果窗口大小为 0 时，就会阻止发送方给接收方传递数据，直到窗口变为非 0 为止，这就是窗口关闭。发送方不得不暂时停止接收数据。发送端主机会时不时的发送 一个叫做窗口探测的数据段，此数据段仅含一个字节以获取最新的窗口大小信息。
TCP拥塞控制，发送端的实现：
由于每次测量的RTT时间都不一样，所以RTO是一个动态的值。
可以根据网络的稳定性和目标服务器的繁忙程度修改 SYN 的重传次数，调整客户端的三次握手时间上限。尽快把错误暴露给应用程序。
SYN攻击就是利用了半连接队列，原理是 给服务端发送大量SYN连接请求，服务端响应SYN+ACK后，又不响应ACK，导致服务端的半连接队列溢出。无法建立新的连接。
如何查看由于 SYN 半连接队列已满，而被丢弃连接的情况？
上面输出的数值是累计值，表示共有多少个 TCP 连接因为半连接队列溢出而被丢弃。隔几秒执行几次，如果有上升的趋势，说明当前存在半连接队列溢出的现象。
如何调整 SYN 半连接队列大小？
增大 tcp_max_syn_backlog syn队列长度 和 somaxconn socket最大连接数
tcp_abort_on_overflow 共有两个值分别是 0 和 1，其分别表示：
0 ：如果 accept 队列满了，那么 server 扔掉 client 发过来的 ack ；
1 ：如果 accept 队列满了，server 发送一个 RST 包给 client，表示废掉这个握手过程和这个连接；
如何查看由于 accept 连接队列已满，而被丢弃的连接？
第二个参数决定断开连接的方式，主要有以下三种方式：
SHUT_RD(0)：关闭连接的「读」这个方向，如果接收缓冲区有已接收的数据，则将会被丢弃，并且后续再收到新的数据，会对数据进行 ACK，然后悄悄地丢弃。也就是说，对端还是会接收到ACK，在这种情况下根本不知道数据已经被丢弃了。
SHUT_WR(1)：关闭连接的「写」这个方向，这就是常被称为「半关闭」的连接。如果发送缓冲区还有未发送的数据，将被立即发送出去，并发送一个 FIN 报文给对端。
SHUT_RDWR(2)：相当于 SHUT_RD 和 SHUT_WR 操作各一次，关闭套接字的读和写两个方向。
FIN_WAIT1 状态的优化：
主动方发送 FIN 报文后，连接就处于 FIN_WAIT1 状态，正常情况下，如果能及时收到被动方的 ACK，
则会很快变为 FIN_WAIT2 状态。
但是当迟迟收不到对方返回的 ACK 时，连接就会一直处于 FIN_WAIT1 状态。此时，内核会定时重发FIN 报文，其中重发次数由 tcp_orphan_retries 参数控制
第一个数值是动态范围的最小值，4096 byte = 4K；
第二个数值是初始默认值，87380 byte ≈ 86K；
第三个数值是动态范围的最大值，4194304 byte = 4096K（4M）；
发送缓冲区是自行调节的，当发送方发送的数据被确认后，并且没有新的数据要发送，就会把发送缓冲区的内存释放掉。
发送缓冲区的调节功能是自动开启的，而接收缓冲区则需要配置 tcp_moderate_rcvbuf 为 1 来开启调节功能：
第一个数值是动态范围的最小值，表示即使在内存压力下也可以保证的最小接收缓冲区大小，4096 byte = 4K；
第二个数值是初始默认值，87380 byte ≈ 86K；
第三个数值是动态范围的最大值，6291456 byte = 6144K（6M）；
一般情况下这些值是在系统启动时根据系统内存数量计算得到的。根据当前 tcp_mem 最大内存页面数是 177120，当内存为 (177120 * 4) / 1024K ≈ 692M 时，系统将无法为新的 TCP 连接分配内存，即TCP 连接将被拒绝。当 TCP 内存小于第 1 个值时，不需要进行自动调节；在第 1 和第 2 个值之间时，内核开始调节接收缓冲区的大小；大于第 3 个值时，内核不再为 TCP 分配新内存，此时新连接是无法建立的；
TCP 可靠性是通过 ACK 确认报文实现的，又依赖滑动窗口提升了发送速度也兼顾了接收方的处理能力。
可是，默认的滑动窗口最大值只有 64 KB，不满足当今的高速网络的要求，要想提升发送速度必须提升滑动窗口的上限，在 Linux 下是通过设置 tcp_window_scaling 为 1 做到的，此时最大值可高达 1GB。滑动窗口定义了网络中飞行报文的最大字节数，当它超过带宽时延积时，网络过载，就会发生丢包。而当它小于带宽时延积时，就无法充分利用网络带宽。因此，滑动窗口的设置，必须参考带宽时延积。内核缓冲区决定了滑动窗口的上限，缓冲区可分为：发送缓冲区 tcp_wmem 和接收缓冲区 tcp_rmem。
Linux 会对缓冲区动态调节，我们应该把缓冲区的上限设置为带宽时延积。发送缓冲区的调节功能是自动打开的，而接收缓冲区需要把 tcp_moderate_rcvbuf 设置为 1 来开启。其中，调节的依据是 TCP 内存范围 tcp_mem。
但需要注意的是，如果程序中的 socket 设置 SO_SNDBUF 和 SO_RCVBUF，则会关闭缓冲区的动态整功能，所以不建议在程序设置它俩，而是交给内核自动调整比较好。
有效配置这些参数后，既能够最大程度地保持并发性，也能让资源充裕时连接传输速度达到最大值。
知客户端 connect 成功返回是在第二次握手，服务端 accept 成功返回是在三次握手成功之后。
TCP 包头格式：
源端口和目标端口是操作系统用来确认是哪个程序监听该数据的。
序号seq：表示当前包的序号，用来解决包顺序问题。
确认号 ack：表示响应确认已收到的包序号。发送端收到这个ack号后就知道这个序号之前的数据都已经接收。用来处理丢包重传问题。
控制位：
窗口大小win：表示当前自己处理数据的剩余缓存大小，用来做流量控制。