TCP协议

标签：协议字节 SYN TCP 发送 cwnd 连接

TCP header

TCP虽然是面向字节流的，但TCP传送的数据单元是报文段。TCP segment由一个固定的20字节的头再加上Offset偏移的多个字节构成。Offset占4个比特位，基本单位是4字节，TCP首部最大能表示2^4 * 4 =60字节。

Sequence Number是包的序号，范围是[0，2^32 - 1]不断循环，TCP传输的每一个字节都按顺序编号，传输的字节流在建立链接的时候要确认初始的序号，可以解决网络包乱序问题。

Acknowledgement Number确认号，是期望对方收到下一个报文段的第一个数据字节的序号，可以解决不丢包的问题。例如B向A发送一个报文序号是100，数据长度50，那么B期待A下一个发来的序号是151。

window活动窗口，是发送报文段方的接受窗口大小，比如发送了一个报文ACK是100，窗口字段是500，这就告诉对方从100号算起，还能向我发500个字节数据。

Checksum检验和包括数据和首部部分，和UDP计算一样。

Urgent Pointer紧急指针，在URG=1时才有意义，指明紧急数据末尾在报文段的位置。

Options里有MSS(最大数据段长度)提高网络利用率用的、窗口扩大(建立TCP连接时约定)、时间戳(计算RTT,防止序号绕回)、SACK等

TCP flag包的类型，主要用于操控TCP状态机，置1为有效。

PSH能在通信时一端按下一个命令对方能立即收到响应
RST复位/拒绝非法报文/拒绝链接，RST=1表明TCP出现严重错误，要释放链接再重新建立
SYN同步序号，当SYN=1,ACK=0时，表明这是一个请求链接报文，如果对方同意就发送SYN=1,ACK=1.
FIN释放一个链接

TCP状态机

链接建立

一个TCP连接需要四个元组来表示是同一个连接（src_ip, src_port, dst_ip, dst_port）准确说是五元组，还有一个是协议。TCP链接的端点叫socket，每一条TCP链接唯一被通信两端的两个端点所确定{（IP1:PORT1）,（IP2:PORT2）}。注意这里的socket和API中的socket概念是不一样的。

创建一个TCP的socket, 同时在内核中创建一个发送缓冲区和一个接收缓冲区;调用write时, 数据会先写入发送缓冲区中;如果发送的字节数太长, 会被拆分成多个TCP的数据包发出;如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;然后应用程序可以调用read从接收缓冲区拿数据;
另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据. 这个概念叫做全双工由于缓冲区的存在, TCP程序的读和写不需要一一匹配。

TCP建立连接的过程又叫三次握手。握手时候主要是要初始化Sequence Number 的初始值。通信的双方要互相通知对方自己的初始化的Sequence Number（缩写为ISN：Inital Sequence Number）——所以叫SYN，全称Synchronize Sequence Numbers。也就上图中的 x 和 y。这个号要作为以后的数据通信的序号，以保证应用层接收到的数据不会因为网络上的传输的问题而乱序（TCP会用这个序号来拼接数据）。还需要协商窗口值大小，是否扩大窗口等。

注意：

SYN连接超时。如果server收到client发来的SYN回了SYN+ACK后client掉线，此时server没有收到client回来的ACK。于是server会重发SYN+ACK。在Linux下，默认重试次数为5次，重试的间隔时间从1s开始每次都翻售，5次的重试时间间隔为1s, 2s, 4s, 8s, 16s，总共31s，第5次发出后还要等32s都知道第5次也超时了，所以，总共需要 1s + 2s + 4s+ 8s+ 16s + 32s = 2^6 -1 = 63s，TCP才会把断开这个连接。
SYN Flood。client不断的发SYN缺不回ACK，服务器会等63s才断开，这样，攻击者就可以把服务器的syn连接的队列耗尽，让正常的连接请求不能处理。于是，Linux下给了一个叫tcp_syncookies的参数来应对这个事——当SYN队列满了后，TCP会通过源地址端口、目标地址端口和时间戳打造出一个特别的Sequence Number发回去（又叫cookie），如果是攻击者则不会有响应，如果是正常连接，则会把这个 SYN Cookie发回来，然后服务端可以通过cookie建连接（即使你不在SYN队列中）。请注意，请先千万别用tcp_syncookies来处理正常的大负载的连接的情况。因为，synccookies是妥协版的TCP协议，并不严谨。对于正常的请求，你应该调整三个TCP参数可供你选择，第一个是：tcp_synack_retries 可以用他来减少重试次数；第二个是：tcp_max_syn_backlog，可以增大SYN连接数；第三个是：tcp_abort_on_overflow 处理不过来干脆就直接拒绝连接了。
ISN。初始化序列号，是在TCP三次连接建立时，用于标识数据段起始位置的序列号。在TCP三次握手中，第一个SYN包和第二个SYN+ACK的包都会包含这个ISN。

ISN的具体数值是不固定的，且不能设置为一个固定值，因为这样容易被攻击者猜出后续序列号，从而遭到攻击。

RFC1948中提出了一个较好的ISN随机生成算法：ISN = M + F(localhost, localport, remotehost, remoteport)。

M是一个计时器，这个计时器每隔4毫秒加1。
F是一个Hash算法，根据源IP、目的IP、源端口、目的端口生成一个随机数值。

一、为什么是三次握手而不是两次？

防止旧的重复连接初始化造成混乱：在网络堵塞的情况下，一个旧的SYN报文可能比新的SYN报文更早到达服务端。如果采用两次握手，服务端在没有收到客户端的确认的情况下，可能会错误地认为连接已经建立，并向客户端发送数据。当新的SYN报文到达时，由于旧的连接已经建立，服务端可能会将新的连接请求当作旧的连接的延续来处理，从而导致数据混乱。而三次握手通过客户端的再次确认，能够确保服务端正确区分新旧连接，防止历史连接初始化了新的连接。
防止已失效的连接请求报文段突然又传送到了服务端：在一次TCP连接中，如果客户端A发送的连接请求SYN报文段没有及时被服务端B接收，而是滞留在网络的某处，客户端A超时重传并成功与服务端B建立连接后，滞留在网络中的旧报文段可能再次被服务端B接收。如果采用两次握手，服务端B会错误地认为客户端A想要建立新的连接，从而浪费资源。而三次握手能够确保服务端B在收到旧报文段时能够识别并拒绝它。

二、为什么是三次握手而不是四次或更多？

同步双方初始序列号：序列号用于确保数据的顺序和完整性。在三次握手中，双方都对请求作出响应，表示数据接受，并初始化发送数据的序列号，保证双方都进入数据可发送和接收的状态。而四次或更多次握手虽然也能实现这一目的，但会增加不必要的开销。
效率与可靠性的平衡：通过三次握手，TCP能够在保证可靠性的同时，尽可能提高连接的建立效率。虽然增加握手次数可以提高可靠性，但也会增加通信开销和连接建立的时间。而三次握手在两者之间找到了一个平衡点，使得TCP在大多数情况下都能够高效地建立连接并保证数据的可靠传输。

链接释放

TCP是全双工的，发送方和接收方都需要FIN和ACK，如果两边同时断连接，那就会就进入到CLOSING状态，然后到达TIME_WAIT状态。

注意：

MSL和TIME_WAIT。MSL是最长的报文寿命，要经过2*MSL后才能进入CLOSED状态。为什么要这么做呢？

1.TIME_WAIT确保有足够的时间让对端收到了ACK，如果被动关闭的那方没有收到Ack，就会触发被动端重发Fin，一来一去正好2个MSL。

2.足够的时间让这个连接不会跟后面的连接混在一起
Keepalive timer保活计时器，服务器每收到一次数据就重新设置一次保活计时器，过了时间就会关闭连接

TCP活动窗口

TCP头里有一个字段叫Window，又叫Advertised-Window，这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。

接收端LastByteRead指向了TCP缓冲区中读到的位置，NextByteExpected指向的地方是收到的连续包的最后一个位置，LastByteRcved指向的是收到的包的最后一个位置，我们可以看到中间有些数据还没有到达，所以有数据空白区。
发送端的LastByteAcked指向了被接收端Ack过的位置（表示成功发送确认），LastByteSent表示发出去了，但还没有收到成功确认的Ack，LastByteWritten指向的是上层应用正在写的地方。
接收端在给发送端回ACK中会汇报自己的AdvertisedWindow = MaxRcvBuffer – LastByteRcvd – 1;
而发送方会根据这个窗口来控制发送数据的大小，以保证接收方可以处理。

#1发送并已收到ack确认的数据。
#2发还没收到ack的。
#3在窗口中还没有发出的（接收方还有空间）。
#4窗口以外的数据（接收方没空间）不允许发送/接收

Zero Window

Zero Window指的是TCP发送方的滑动窗口大小为0。这通常意味着TCP接收方的接收缓存已经满了，没有空间再接收新的数据。

虽然接收缓存为0，但TCP接收方仍然可以接收一些特定类型的报文，如数据长度为0的ACK报文、FIN报文或URG=1但数据长度为0的报文。这些报文不包含实际的数据，因此不会增加接收缓存的负担。

为了打破Zero Window状态，TCP发送方会启动Zero Window Probe机制，周期性地向接收方发送零窗口探测包（Zero Window Probes, ZWP），以探测接收方的窗口是否重新打开。如果3次过后还是0的话，有的TCP实现就会发RST把链接断了。

流量控制

利用活动窗口可以实现流量控制，让发送方的速率不要过快，接收方来的急接收。

Silly Window Syndrome

如果接受方的缓存满了，假如接受方进程一次只取出一个字节的数据，然后向发送方发确认，并把窗口设置成一个字节，发送方看到有一个字节腾出就会发送一个字节的数据。

TCP+IP有40个字节，为了一个字节的数据，发41字节过去很不划算。网络上有个MTU，对于以太网来说，MTU是1500字节，除去TCP+IP头的40个字节，真正的数据传输可以有1460，这就是所谓的MSS（Max Segment Size）

注意，TCP的RFC定义这个MSS的默认值是536，这是因为 RFC 791里说了任何一个IP设备都得最少接收576尺寸的大小（实际上来说576是拨号的网络的MTU，而576减去IP头的20个字节就是536）。

Silly Windows Syndrome这个现像就像是本来可以坐200000人的飞机里只做了一两个人。要解决这个问题也不难，就是避免对小的window size做出响应，直到有足够大的window size再响应，这个思路可以同时实现在sender和receiver两端。

如果这个问题是由Receiver端引起的，那么就会使用 David D Clark’s 方案。在receiver端，如果收到的数据导致window size小于某个值，可以直接ack(0)回sender，这样就把window给关闭了，也阻止了sender再发数据过来，等到receiver端处理了一些数据后windows size 大于等于了MSS，或者，receiver buffer有一半为空，就可以把window打开让send 发送数据过来。
如果这个问题是由Sender端引起的，那么就会使用著名的 Nagle’s algorithm。这个算法的思路也是延时处理，他有两个主要的条件：1）要等到 Window Size>=MSS 或是 Data Size >=MSS，2）收到之前发送数据的ack回包，他才会发数据，否则就是在攒数据。

TCP重传机制

RTT

Round Trip Time，也就是一个数据包从发出去到回来的时间。这样发送端就大约知道需要多少的时间，从而可以方便地设置Timeout——RTO（Retransmission TimeOut）。

快速重传

TCP引入了一种叫Fast Retransmit 的算法，不以时间驱动，而以数据驱动重传。也就是说，如果，包没有连续到达，就ack最后那个可能被丢了的包，如果发送方连续收到3次相同的ack，就重传。Fast Retransmit的好处是不用等timeout了再重传。

SACK

Selective Acknowledgment这种方式需要在TCP头里加一个SACK的东西，ACK还是Fast Retransmit的ACK，SACK则是汇报收到的数据碎版。

这样，在发送端就可以根据回传的SACK来知道哪些数据到了，哪些没有到。于是就优化了Fast Retransmit的算法。

TCP拥塞控制

若网络中的某一个资源需求超过了该资源所提供的可用部分，网络就会变坏，这种情况叫拥塞。

TCP拥塞控制也是基于窗口的控制，发送方会维持一个拥塞窗口(cwnd),网络拥堵就减小窗口大小。

发送方怎么知道发送了拥堵呢？

当发送方没按时收到对方的ACK，在超时重传计时器启动之后，就判断发生了拥堵。

拥塞控制是为了防止更多的数据注入网络中，拥塞控制是一个全局的过程涉及到主机、路由器等。而流量控制是点对点的通信量的控制，主要是抑止发送方发送的速率。

拥塞控制主要有4个算法：慢启动、拥塞避免、快重传、快速恢复。

慢启动Slow Start

由小到大的逐渐注入到网络中的字节数据，连接建好的开始先初始化cwnd = 1，表明可以传一个SMSS(最报文段)大小的数据。每当收到一个ACK，cwnd++; 呈线性上升。每当过了一个RTT，cwnd = cwnd*2; 呈指数让升，当上升到>ssthresh,就会进入拥塞避免算法。

拥塞避免算法 – Congestion Avoidance

当cwnd >= ssthresh时，就会进入“拥塞避免算法”。一般来说ssthresh的值是65535，单位是字节，当cwnd达到这个值时后，算法如下：

1）收到一个ACK时，cwnd = cwnd + 1/cwnd

2）当每过一个RTT时，cwnd = cwnd + 1

这样就可以避免增长过快导致网络拥塞，慢慢的增加调整到网络的最佳值。很明显，是一个线性上升的算法。

拥塞状态时的算法

当丢包的时候，会有两种情况：

1）等到RTO超时，重传数据包。TCP认为这种情况太糟糕，反应也很强烈。

- sshthresh = cwnd /2
- cwnd 重置为 1
- 进入慢启动过程

2）Fast Retransmit算法，也就是在收到3个duplicate ACK时就开启重传，而不用等到RTO超时。

-TCP Tahoe的实现和RTO超时一样。
-TCP Reno的实现是：
- cwnd = cwnd /2
- sshthresh = cwnd
- 进入快速恢复算法——Fast Recovery

上面我们可以看到RTO超时后，sshthresh会变成cwnd的一半，这意味着，如果cwnd<=sshthresh时出现的丢包，那么TCP的sshthresh就会减了一半，然后等cwnd又很快地以指数级增涨爬到这个地方时，就会成慢慢的线性增涨。

快速恢复算法 – Fast Recovery

快速重传和快速恢复算法一般同时使用。

进入Fast Recovery之前，cwnd 和 sshthresh已被更新：

cwnd = cwnd /2
sshthresh = cwnd

然后，真正的Fast Recovery算法如下：

cwnd = sshthresh + 3 * MSS （3的意思是确认有3个数据包被收到了）
重传Duplicated ACKs指定的数据包
如果再收到 duplicated Acks，那么cwnd = cwnd +1
如果收到了新的Ack，那么，cwnd = sshthresh ，然后就进入了拥塞避免的算法了。

可以看到快速恢复算法依赖3个ACK，3个重复的Acks并不代表只丢了一个数据包，很有可能是丢了好多包。但这个算法只会重传一个，而剩下的那些包只能等到RTO超时，于是，进入了恶梦模式——超时一个窗口就减半一下，多个超时会超成TCP的传输速度呈级数下降，而且也不会触发Fast Recovery算法了。

TCP New Reno

于是，1995年，TCP New Reno（参见 RFC 6582 ）算法提出来，主要就是在没有SACK的支持下改进Fast Recovery算法的

当sender这边收到了3个Duplicated Acks，进入Fast Retransimit模式，开发重传重复Acks指示的那个包。如果只有这一个包丢了，那么，重传这个包后回来的Ack会把整个已经被sender传输出去的数据ack回来。如果没有的话，说明有多个包丢了。我们叫这个ACK为Partial ACK。
一旦Sender这边发现了Partial ACK出现，那么，sender就可以推理出来有多个包被丢了，于是乎继续重传sliding window里未被ack的第一个包。直到再也收不到了Partial Ack，才真正结束Fast Recovery这个过程

粘包问题

首先粘包是指应用层的数据包粘到一起了，站到传输层的角度TCP在接收一个个报文的时候按序号放好在缓冲区中，在应用层的角度这就是一串字节数据，应用层并不知道那个是开始部分哪个是结束部分。

TCP是不能解决这个粘包问题的，那如何避免呢？

总的来说是要明确两个包之间的边界或者可以明确的去使用分割符去区分。对于定长的包可以每次按固定的大小去读取，变长的包需要双方约定好每次读多少或者定一个分隔符。

前面说的UDP会不会存在这个粘包的问题呢？

UDP首先是面向数据报的，站在应用层的角度，要么接收，要么就接受到完整的报文。UDP中还有一个16位UDP长度（数据+头）来方便区分，所以UDP不会存在粘包问题。

再认识认识面向字节流

无边界性：TCP并不关心应用程序一次发送了多少字节的数据，它根据当前网络状况，可能将这些数据分成多个包（segment）进行发送，也可能将多个发送请求合并成一个包发送。同样，接收端也是如此，TCP并不保证一次接收的数据就是应用程序一次发送的数据。这种特性称为“无边界性”。
字节流：TCP将数据视为无结构的字节序列（即字节流）。应用程序在发送数据时，TCP会将这些数据视为一个连续的字节序列，并按照这个序列的顺序进行传输。接收端在接收到数据后，也会按照这个顺序将数据传递给应用程序。
可靠传输：TCP通过一系列机制（如序列号、确认应答、超时重传、流量控制、拥塞控制等）保证了数据的可靠传输。这些机制都是基于字节流来进行的，例如，TCP通过序列号来跟踪每个字节的传输情况，以确保数据的顺序性和完整性。
应用程序的缓冲：由于TCP的“无边界性”，应用程序在接收数据时，需要有一个缓冲区来暂存接收到的数据。这是因为TCP可能一次发送多个数据包，也可能将多个发送请求合并成一个数据包发送，所以应用程序需要等待足够的数据到达后，再进行处理。

TCP异常

进程终止

当一个进程终止时，它拥有的所有资源，包括打开的文件描述符和套接字（sockets），都会被操作系统自动释放。
如果该进程是一个TCP连接的客户端或服务端，并且连接是活动的，那么TCP连接的另一端（如果还在运行）会收到一个FIN包，表示连接正在被关闭。
收到FIN包的一方会进入TIME_WAIT或CLOSE_WAIT状态，并最终关闭连接。

机器重启

当机器重启时，所有正在运行的进程和它们拥有的资源（包括TCP连接）都会被终止。
和进程终止一样，TCP连接的另一端会收到FIN包（如果连接在重启前是活动的）并关闭连接。
重启后的机器不会记住重启前的TCP连接状态。

机器掉电/网线断开

当机器掉电或网线断开时，TCP连接会突然中断，没有机会发送FIN包。
TCP连接的另一端不会立即知道连接已经中断，因为它没有收到FIN包。但是，它可能会通过以下几种方式检测到连接的中断：
1. 应用层写入操作：当应用层尝试写入数据时，如果底层TCP栈发现连接已经中断（例如，通过发送数据并收到ICMP错误消息），它会通知应用层连接已关闭。
2. TCP保活机制：TCP有一个内置的保活定时器（keepalive timer），用于检测长时间空闲的连接是否仍然有效。如果定时器到期并且连接仍然空闲，TCP会发送一个保活探测包给对端。如果对端没有响应，TCP会多次重试，并在最终放弃后关闭连接。
3. 应用层协议检测：某些应用层协议（如HTTP长连接、QQ等）会有自己的连接检测机制。这些机制通常包括定期发送心跳包或检测对端是否在规定时间内响应。

Listen

当一个TCP连接正在建立时，Linux内核会维护两个队列来管理这些连接：

半连接队列（SYN Queue）

这个队列保存的是那些已经发送了SYN包但还没有收到对端ACK包的连接请求。

这些连接处于SYN_SENT（对于客户端）或SYN_RECV（对于服务器端）状态。

半连接队列的大小由/proc/sys/net/ipv4/tcp_max_syn_backlog参数控制，但在实际应用中，其实际大小还受限于系统的TCP/IP栈的内存使用情况和其他因素。
全连接队列（Accept Queue）

也叫已建立连接队列或监听队列，它保存的是那些已经完成了三次握手，但应用层还没有调用accept()函数来取走的连接。这些连接处于ESTABLISHED状态，但在应用层看来，它们仍然是“待处理”的。

全连接队列的大小由listen()函数的第二个参数（backlog）和/proc/sys/net/core/somaxconn（这个参数定义了单个监听socket的默认最大队列长度）共同决定。实际的全连接队列大小是这两个值中的较小值，然后再加1（这个+1是为了防止全连接队列和半连接队列溢出时的竞争条件）。

#include <sys/types.h>         
#include <sys/socket.h>
int listen(int sockfd, int backlog);

可以看出当全连接队列满了时，新的连接请求就无法再进入ESTABLISHED状态，它们可能会被丢弃，或者根据TCP的拥塞控制算法进行重传。这种情况下，你可能会在服务器上看到大量的SYN_RECV状态连接，并且客户端可能会遇到连接超时的问题。

基于TCP应用层协议

HTTP
HTTPS
SSH
Telnet
FTP
SMTP

标签：协议,字节,SYN,TCP,发送,cwnd,连接
From： https://blog.csdn.net/weixin_53425006/article/details/139290090