一、端口号

1、端口号范围划分

2、知名端口号(Well-Know Port Number)

3、netstat

4、pidof

二、UDP协议

1、UDP协议段格式

2、UDP的特点

3、面向数据报

4、UDP的缓冲区

5、UDP使用注意事项

6、基于UDP的应用层协议

三、TCP协议

1、TCP协议段格式

2、确认应答机制（ACK）

3、超时重传机制

4、连接管理机制

4.1、什么是连接

4.2、连接过程

4.3、断开过程

4.4、状态变化

5、TIME_WAIT状态

6、解决TIME_WAIT状态引起的bind失败的方法

7、流量控制

8、滑动窗口

9、拥塞控制

10、延迟应答

11、捎带应答

12、面向字节流

13、粘包问题

14、TCP异常情况

15、TCP小结

16、 TCP连接管理队列

四、TCP/UDP对比

一、端口号

端口号(Port)标识了一个主机上进行通信的不同的应用程序：

在TCP/IP协议中，用 "源IP"，"源端口号"，"目的IP"，"目的端口号"，"协议号" 这样一个五元组来标识一个通信(可以通过netstat -n查看)。

1、端口号范围划分

0 - 1023：知名端口号，HTTP，FTP，SSH等这些广为使用的应用层协议，他们的端口号都是固定的。
1024 - 65535：操作系统动态分配的端口号。客户端程序的端口号，就是由操作系统从这个范围分配的。

2、知名端口号(Well-Know Port Number)

有些服务器是非常常用的，为了使用方便，人们约定一些常用的服务器，都是用以下这些固定的端口号：

ssh服务器，使用22端口。
ftp服务器，使用21端口。
telnet服务器，使用23端口。
http服务器，使用80端口。
https服务器，使用443端口。

执行下面的命令，可以看到知名端口号：

cat /etc/services

3、netstat

netstat是一个用来查看网络状态的重要工具。

语法： netstat [选项]

功能：查看网络状态

常用选项：

n：拒绝显示别名，能显示数字的全部转化成数字。
l：仅列出有在 Listen (监听) 的服务状态。
p：显示建立相关链接的程序名。
t：(tcp)仅显示tcp相关选项。
u：(udp)仅显示udp相关选项。
a：(all)显示所有选项。

4、pidof

在查看服务器的进程id时非常方便。

语法： pidof [进程名]。

功能：通过进程名, 查看进程id。

二、UDP协议

1、UDP协议段格式

UDP协议规定报文的前8个字节就是报头。
16位UDP长度，表示整个数据报(UDP首部+UDP数据)的最大长度。
如果校验和出错，就会直接丢弃。

tcp/ip是属于操作系统的，Linux系统是用C语言实现的，这就说明协议是使用C语言实现的。因此协议的本质是结构化数据，即报头的本质是struct：

struct udp_header
{
    uint16_t src_port;
    uint16_t dst_port;
    uint16_t udp_len;
    uint16_t check;
}

补充内容：

在应用层，因为离用户太近，自定义协议随时都可能发生变化，所以需要进行序列化与反序列化的操作来把数据以字符串的方式传递，防止内存对齐等问题导致的错误。

但是传输层不同，TCP/IP协议一旦定好，就不会再改变了，所以直接使用结构体字段进行传递。因为它们属于操作系统的，而操作系统可以做到统一性，必须保证报头的大小是8字节，因此不需要考虑内存对齐的问题。

2、UDP的特点

UDP传输的过程类似于寄信：

无连接：知道对端的IP和端口号就直接进行传输，不需要建立连接。
不可靠：没有确认机制，没有重传机制。如果因为网络故障该段无法发到对方，UDP协议层也不会给应用层返回任何错误信息。
面向数据报：不能够灵活的控制读写数据的次数和数量。

3、面向数据报

应用层交给UDP多长的报文，UDP原样发送，既不会拆分，也不会合并。

用UDP传输100个字节的数据：

如果发送端调用一次sendto，发送100个字节，那么接收端也必须调用对应的一次recvfrom，接收100个字节。而不能循环调用10次recvfrom，每次接收10个字节。

4、UDP的缓冲区

UDP没有真正意义上的发送缓冲区。调用sendto会直接交给内核，由内核将数据传给网络层协议进行后续的传输动作。
UDP具有接收缓冲区。但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致。如果缓冲区满了，再到达的UDP数据就会被丢弃。

UDP的socket既能读，也能写，这个概念叫做全双工。

当我们传输数据时，会把对每一个报文都new一块缓冲区，并把报文封装成struct sk_buffer。以后发送或读取时，就把需要发送或读取的 struct sk_buffer 拷贝到UDP的大缓冲区里，统一发送读取。

5、UDP使用注意事项

我们注意到，UDP协议首部中有一个16位的最大长度。也就是说一个UDP能传输的数据最大长度是64K(包含UDP首部)。

然而64K在当今的互联网环境下，是一个非常小的数字。如果我们需要传输的数据超过64K，就需要在应用层手动的分包，多次发送，并在接收端手动拼装。

6、基于UDP的应用层协议

NFS：网络文件系统
TFTP：简单文件传输协议
DHCP：动态主机配置协议
BOOTP：启动协议(用于无盘设备启动)
DNS：域名解析协议

三、TCP协议

TCP全称为 "传输控制协议(Transmission Control Protocol")。人如其名，要对数据的传输进行一个详细的控制。

1、TCP协议段格式

源/目的端口号：表示数据是从哪个进程来，到哪个进程去。
32位序号/32位确认号。
4位TCP报头长度：表示该TCP头部有多少个32位bit(有多少个4字节)。所以TCP头部最大长度是15 * 4（1111B * 4） = 60。
6位标志位：
URG：紧急指针是否有效，标识该报文中含有紧急数据。
ACK：该报文是一个确认应答报文，也有可能会携带数据。
PSH：提示接收端应用程序立刻从TCP缓冲区把数据读走。
RST：对方要求重新建立连接。我们把携带RST标识的称为复位报文段。
SYN：该报文是一个请求建立连接的报文。我们把携带SYN标识的称为同步报文段。
FIN：通知对方，本端要关闭了，我们称携带FIN标识的为结束报文段。
16位窗口大小。
16位校验和：发送端填充，CRC校验。接收端校验不通过，则认为数据有问题。此处的检验和不光包含TCP首部，也包含TCP数据部分。
16位紧急指针：标识哪部分数据是紧急数据。
40字节头部选项。

由于TCP协议的标准报头是20个字节，另外还需要算上选项大小，所以最终报头大小是20字节 + 选项大小，被记录在4位首部长度中。又因为4位首部长度的记录范围是[0，60]。所以报头的总大小范围是[20，60]。

接收端会在同一时刻收到各种各样的报文请求，这些报文请求都不同，对应的处理动作就不同。标志位就是用来标识不同类型的报文的。

16位紧急指针，是紧急数据在有效载荷中的偏移量。紧急数据只有一个字节。紧急指针的用途在于，我们在网上上传数据等场景时，如果需要暂停上传，就可以通过紧急指针来发送暂停命令。否则按照正常数据传输流程，等接收端收到暂停请求时，可能已经过去很久了。紧急指针又称为带外数据，可以在正常的传输流程下，不走主线，另外开辟一条链路传递数据。

补充内容：

recv 函数与 send 函数的 flag 参数可以设置成 MSG_OOB，即进行带外传输与带外发送。

当服务器与客户端认为连接建立状态不一致时，会把RST标志位置 1，进行连接重置。

2、确认应答机制（ACK）

在网络通信过程中，有诸多不可靠的问题，比如：丢包、乱序、重复、校验失败、发送太快/太慢、网络出问题等等。出现这些问题，最根本的原因是通信双方之间的距离变长了。

为了解决这些问题，首先需要双方知道问题已经发生了。可以通过确认应答机制来实现。

无论是请求还是响应，双方在进行交互的时候，通信发送的都是 TCP报头+有效载荷。

TCP将每个字节的数据都进行了编号，即为序列号。

每一个ACK都带有对应的确认序列号，意思是告诉发送者，我已经收到了哪些数据。下一次你从哪里开始发。

把发送、接收缓冲区看作一个char类型的数组，把数据拷贝到缓冲区后，这些数据天然就有了自己的下标，一段数据区间最大的下标，就是序号，下一个数据区间最小的下标就是确认序号。

序号：具有唯一性的序号，双方通信时，每一个报文都有序号。
确认序号X：X-1之前的报文已经全部收到了，下次发请从X编号开始发送。确认序号可以允许少量的ACK丢失，更细粒度的确认丢包原因。

发送端如果收到了应答，就认为接收端收到了对应的数据。否则无论接收端收没收到数据，发送端都认为数据丢失了。

从发送端发送数据，到进行下一步操作之前，需要有一个等待时间，用来等待接收端发送回来的应答。这个等待时间叫做时间窗口。如果超过了这个时间还没有收到应答，发送端就认为发送的数据已经丢失。

确认应答报文也有可能捎带数据，如果稍带了数据，长度会比纯应答报文长。

3、超时重传机制

主机A发送数据给B之后，可能因为网络拥堵等原因，数据无法到达主机B。如果主机A在一个特定时间间隔内没有收到B发来的确认应答，就会进行重发。

但是，主机A未收到B发来的确认应答，也可能是因为ACK丢失了。

因此主机B会收到很多重复数据。那么TCP协议需要能够识别出那些包是重复的包，并且把重复的丢弃掉。这时候我们可以利用前面提到的序列号，就可以很容易做到去重的效果。

那么，超时的时间如何确定?

最理想的情况下，找到一个最小的时间, 保证 "确认应答一定能在这个时间内返回"。
但是这个时间的长短，随着网络环境的不同, 是有差异的。
如果超时时间设的太长，会影响整体的重传效率。
如果超时时间设的太短，有可能会频繁发送重复的包。

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

Linux中(BSD Unix和Windows也是如此)，超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。
如果重发一次之后，仍然得不到应答，等待 2*500ms 后再进行重传。
如果仍然得不到应答，等待 4*500ms 进行重传。依次类推，以指数形式递增。
累计到一定的重传次数，TCP认为网络或者对端主机出现异常，强制关闭连接。

4、连接管理机制

4.1、什么是连接

连接是TCP协议自动做的，即是OS自动做的。在OS中一定已经存在了多个建立好的连接，OS需要把这些连接管理起来，这是一个先描述，再组织的过程。OS内为了管理连接而要维护特定的数据结构，就需要内存与cpu的资源，因此创建维护连接是有成本的。连接相关的所有字段，包括连接状态、等待重传时间等等，都保存在该数据结构中。

在正常情况下，TCP要经过三次握手建立连接，四次挥手断开连接。

三次握手的过程，由双方的OS系统中的TCP层自主完成。

调用 connect 函数，触发建立连接，等待建立完成。

调用 accept 函数，等待建立完成，获取连接。

4.2、连接过程

当客户端经过两次握手，并且发送了应答请求后，客户端就认为连接建立完成了。而服务器只有在收到应答后，才会认为连接建立完成。因此就有可能出现以下情况：最后的应答在传输过程中丢失，导致客户端认为连接已经建立，而服务器认为连接还没有建立。这时客户端直接向服务器发送数据，服务器会直接在应答中把RST标志位置1，进行连接重置。

至于为什么是三次握手，别的次数不行。

首先两次握手绝对不行，因为采用两次握手的话，对于服务器而言，收到客户端的 SYN 数据报后，再发送一个应答，服务器就认为连接建立完成了，就需要建立对应的数据结构把连接管理起来。而客户端想要攻击服务器，就可以不用理会服务器发送来的应答，继续不断地向服务器发送连接请求，这样次数多了，服务器内的资源就会被用完，有巨大的隐患。

其次，由于连接请求一定是客户端发起的，且最后一个发送ACK报文的一方首先确认建立起连接。于是，如果进行奇数次握手，那么先确认建立连接的就是客户端，偶数次握手则是服务器先建立连接。如果是偶数次握手的话，就把连接可能会发生异常的不确定性给了服务器，由服务器端承担成本，而服务器端面对的是多个客户端，造成的后果会更严重。

所以进行三次握手，没有明显的设计漏洞，一旦建立连接出现异常，成本嫁接到client，server端成本较低。三次握手是验证全双工通信信道通畅的最小成本，双方都可以验证自己既能收又能发。

4.3、断开过程

断开请求可能由任意一方发起，并需要经过另一方的同意。客户端发送FIN请求，并且收到服务器的ASK应答后，确认服务器得知该请求。服务器向客户端发送FIN请求，并且收到客户端发送的ASK应答后，服务器确认客户端得知该请求，此时连接断开。

4.4、状态变化

服务端状态转化：

[CLOSED -> LISTEN] 服务器端调用listen后进入LISTEN状态，等待客户端连接。
[LISTEN -> SYN_RCVD] 一旦监听到连接请求(同步报文段)，就将该连接放入内核等待队列中，并向客户端发送SYN确认报文。
[SYN_RCVD -> ESTABLISHED] 服务端一旦收到客户端的确认报文，就进入ESTABLISHED状态，可以进行读写数据了。
[ESTABLISHED -> CLOSE_WAIT] 当客户端主动关闭连接(调用close)，服务器会收到结束报文段，服务器返回确认报文段并进入CLOSE_WAIT。
如果服务器端进入CLOSE_WAIT状态后，迟迟不调用colse，那么服务器端会保持在CLOSE_WAIT状态很长一段时间，客户端将直接关闭，不会再完成四次握手。所以服务器端在通信时，一定要记得关闭文件描述符，否则连接一直维持，浪费资源。
[CLOSE_WAIT -> LAST_ACK] 进入CLOSE_WAIT后说明服务器准备关闭连接(需要处理完之前的数据)。当服务器真正调用close关闭连接时，会向客户端发送FIN，此时服务器进入LAST_ACK状态，等待最后一个ACK到来(这个ACK是客户端确认收到了FIN)。
如果因为服务器没有调用close连接而迟迟保持在CLOSE_WAIT，导致客户端已经退出了。这时在关闭进程把所有的文件描述符都关掉，服务器端也会进入 LAST_ACK状态，但是因为客户端已经关了，所以不可能在收到最后一个ACK了。因此过一段时间服务器会自动强制关闭。
[LAST_ACK -> CLOSED] 服务器收到了对FIN的ACK，彻底关闭连接。

客户端状态转化：

[CLOSED -> SYN_SENT] 客户端调用connect，发送同步报文段。
[SYN_SENT -> ESTABLISHED] connect调用成功，则进入ESTABLISHED状态，开始读写数据。
[ESTABLISHED -> FIN_WAIT_1] 客户端主动调用close时，向服务器发送结束报文段，同时进入FIN_WAIT_1。
[FIN_WAIT_1 -> FIN_WAIT_2] 客户端收到服务器对结束报文段的确认，则进入FIN_WAIT_2，开始等待服务器的结束报文段。
[FIN_WAIT_2 -> TIME_WAIT] 客户端收到服务器发来的结束报文段，进入TIME_WAIT，并发出LAST_ACK。
主动断开的一方，要进入TIME_WAIT状态，这是一种临时性状态，会持续一小段时间，过一会就没了。
TIME_WAIT状态本身就是一种连接状态。所以尽管此时四次挥手已经完成，但是由于断开发起方仍然处于TIME_WAIT状态，所以发起方的OS仍然要维护连接结构体，即发起方使用的端口号仍然在被使用。
[TIME_WAIT -> CLOSED] 客户端要等待一个2MSL(Max Segment Life，报文最大生存时间)的时间，才会进入CLOSED状态。

下图是TCP状态转换的一个汇总：

较粗的虚线表示服务端的状态变化情况。
较粗的实线表示客户端的状态变化情况。
CLOSED是一个假想的起始点, 不是真实状态。

5、TIME_WAIT状态

TCP协议规定，主动关闭连接的一方要处于TIME_ WAIT状态，等待两个MSL(maximum segment lifetime，报文最大生存时间)的时间后才能回到CLOSED状态。

MSL在RFC1122中规定为两分钟，但是各操作系统的实现不同，在Centos7上默认配置的值是60s。可以通过 cat /proc/sys/net/ipv4/tcp_fin_timeout 查看msl的值：

TIME_WAIT的时间是2MSL，是因为：

MSL是TCP报文的最大生存时间，因此TIME_WAIT持续存在2MSL的话就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失（否则服务器立刻重启，可能会收到来自上一个进程的迟到的数据，但是这种数据很可能是错误的）。
同时也是在理论上保证最后一个报文可靠到达（假设最后一个ACK丢失，那么服务器会再重发一个FIN。这时虽然客户端的进程不在了，但是TCP连接还在，仍然可以重发LAST_ACK）。

如果不等待TIME_ WAIT状态，有可能会发生新建立的连接使用原来的端口号，并收到了上一个连接残留下来的报文，造成报文混乱的问题。

6、解决TIME_WAIT状态引起的bind失败的方法

在server的TCP连接没有完全断开之前不允许重新监听，某些情况下可能是不合理的：

服务器需要处理非常大量的客户端的连接(每个连接的生存时间可能很短，但是每秒都有很大数量的客户端来请求)。
这个时候如果由服务器端主动关闭连接(比如某些客户端不活跃，就需要被服务器端主动清理掉)，就会产生大量TIME_WAIT连接。
由于我们的请求量很大，就可能导致TIME_WAIT的连接数很多，每个连接都会占用一个通信五元组(源ip，源端口，目的ip，目的端口，协议)。其中服务器的ip和端口和协议是固定的。如果新来的客户端连接的ip和端口号和TIME_WAIT占用的链接重复了，就会出现问题。

如果服务器是主动断开的一方，又不希望因为服务器端进入 TIME_WAIT 状态，无法立即重起，则可以使用函数接口setsockopt设置套接字选项：

int setsockopt(int sockfd, int level, int optname,
                      const void *optval, socklen_t optlen);

setsockopt 函数的参数列表中， sockfd 代表是哪一个套接字。 level 代表在哪一层，通常写成 SOL_SOCKET ，即在系统层面。 optname 是选项名称，一般设置成 SO_REUSEADDR ，表示地址可以复用。 optval 表示要把我们已经选定的属性设置成什么值，比如可以把该值设置为整型变量 1 ，表示地址复用为真，例如：

int opt = 1;
setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));

7、流量控制

接收端处理数据的速度是有限的。如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送，就会造成丢包，继而引起丢包重传等等一系列连锁反应。

因此TCP支持根据接收端的处理能力，来决定发送端的发送速度。这个机制就叫做流量控制(Flow Control)。

接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 "窗口大小" 字段，通过ACK端通知发送端。
窗口大小字段越大，说明网络的吞吐量越高。
接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端。
发送端接受到这个窗口之后，就会减慢自己的发送速度。
如果接收端缓冲区满了，就会将窗口置为0。这时发送方不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。

接收端如何把窗口大小告诉发送端呢？回忆我们的TCP首部中，有一个16位窗口字段，就是存放了窗口大小信息。

在客户端与服务器申请建立连接时，客户端就已经把自己的16为窗口大小告诉了服务器，这时客户端与服务器的第一次交流。

那么问题来了，16位数字最大表示65535，TCP窗口最大就是65535字节么?

实际上，TCP首部40字节选项中还包含了一个窗口扩大因子M，实际窗口大小是窗口字段的值左移 M 位。

8、滑动窗口

TCP协议，可靠性是主要研究的问题，但不是全部，效率问题也是TCP考虑的问题。

对每一个发送的数据段，都要给一个ACK确认应答。收到ACK后再发送下一个数据段。这样做有一个比较大的缺点，就是性能较差。尤其是数据往返的时间较长的时候。

既然这样一发一收的方式性能较低，那么我们一次发送多条数据，就可以大大的提高性能(其实是将多个段的等待时间重叠在一起了)。

因此TCP协议需要进行并发访问。且发送端并发发送，一定要在对方能够接收的前提下进行。发送方最大一次可以向对方发送的数据量，由对方的窗口大小决定。

滑动窗口本质上是两个数组下标维护的区间，是发送缓冲区的一部分，在滑动窗口区间中的数据可以不用收到应答，直接发送。
窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。上图的窗口大小就是4000个字节(四个段)。
发送前四个段的时候，不需要等待任何ACK，直接发送。
收到第一个ACK后，滑动窗口向后移动，继续发送第五个段的数据，依次类推。
操作系统内核为了维护这个滑动窗口，需要开辟发送缓冲区来记录当前还有哪些数据没有应答。只有确认应答过的数据，才能从缓冲区被标识为无效数据。
窗口越大，则网络的吞吐率就越高。

需要注意的是：

滑动窗口只能向右滑动，而不能向左滑动，因为滑动窗口的左侧是已经发送过，并接收到了应答的已发送无效数据。
滑动窗口的大小是浮动的，可以变大变小，完全取决于对方的接受能力。
TCP需要保证可靠性，因此发送端接收到的应答是有序的，应答序号表示下一次要从哪里开始发送，接收端只需要把滑动窗口的起始位置设置为该序号，结束位置设置为该序号加上16位窗口大小就可以了。
发送缓冲区相当于一个环形队列，因此滑动窗口可以一直向右移动，不会出现越界的情况。

那么如果出现了丢包，如何进行重传？这里分两种情况讨论：

情况一：数据包已经抵达，ACK被丢了。

这种情况下，部分ACK丢了并不要紧，因为可以通过后续的ACK进行确认。收到了后面的ACK，就说明前面的数据一定都被接收端收到了。

情况二：数据包丢了。

当某一段报文段丢失之后，发送端会一直收到 1001 这样的ACK，就像是在提醒发送端 "我想要的是 1001" 一样。
如果发送端主机连续三次收到了同样一个 "1001" 这样的应答，就会将对应的数据 1001 - 2000 重新发送。
这个时候接收端收到了 1001 之后，再次返回的ACK就是7001了(因为2001 - 7000)接收端其实之前就已经收到了，被放到了接收端操作系统内核的接收缓冲区中。

9、拥塞控制

虽然TCP有了滑动窗口，能够高效可靠的发送大量的数据。但是如果在刚开始阶段就发送大量的数据，仍然可能引发问题。

因为网络上有很多的计算机，可能当前的网络状态就已经比较拥堵，在不清楚当前网络状态下，贸然发送大量的数据，是很有可能引起雪上加霜的。

如果发送方发送了大量报文，只接收到了少量的应答，则说明网络拥堵了。如果这时TCP协议使用超时重传机制，由于网络中所有主机使用的都是TCP协议，则会同时补发大量的数据，更加使网络不堪重负。

TCP引入慢启动机制，先发少量的数据，探探路，摸清当前的网络拥堵状态，再决定按照多大的速度传输数据。

此处引入一个概念程为拥塞窗口。
发送开始的时候，定义拥塞窗口大小为1。
每次收到一个ACK应答，拥塞窗口加1。
每次发送数据包的时候，将拥塞窗口和接收端主机反馈的16位窗口大小做比较，取较小的值作为实际发送的滑动窗口大小。

像上面这样的拥塞窗口增长速度，是指数级别的。"慢启动" 只是指初使时慢，但是增长速度非常快。

为了不增长的那么快，因此不能使拥塞窗口单纯的加倍。
此处引入一个叫做慢启动的阈值。
当拥塞窗口超过这个阈值的时候，不再按照指数方式增长，而是按照线性方式增长。

当TCP开始启动的时候，慢启动阈值等于窗口最大值。
在每次超时重发的时候，慢启动阈值会变成原来的一半，同时拥塞窗口置回1。

少量的丢包，我们仅仅是触发超时重传。大量的丢包，我们就认为网络拥塞。

当TCP通信开始后，网络吞吐量会逐渐上升。随着网络发生拥堵，吞吐量会立刻下降。

拥塞控制，归根结底是TCP协议想尽可能快的把数据传输给对方，但是又要避免给网络造成太大压力的折中方案。

10、延迟应答

如果接收数据的主机立刻返回ACK应答，这时候返回的窗口可能比较小。

假设接收端缓冲区为1M。一次收到了500K的数据。如果立刻应答，返回的窗口就是500K。
但实际上可能处理端处理的速度很快，10ms之内就把500K数据从缓冲区消费掉了。
在这种情况下，接收端处理还远没有达到自己的极限，即使窗口再放大一些，也能处理过来。
如果接收端稍微等一会再应答，比如等待200ms再应答，那么这个时候返回的窗口大小就是1M。

一定要记得，窗口越大，网络吞吐量就越大，传输效率就越高。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率。

那么所有的包都可以延迟应答么? 肯定也不是。

数量限制：每隔N个包就应答一次。
时间限制：超过最大延迟时间就应答一次。

具体的数量和超时时间，依操作系统不同也有差异。一般N取2，超时时间取200ms。

11、捎带应答

在延迟应答的基础上，我们发现，很多情况下，客户端服务器在应用层也是 "一发一收" 的。意味着客户端给服务器说了 "How are you"，服务器也会给客户端回一个 "Fine, thank you"。那么这个时候ACK就可以搭顺风车，和服务器回应的 "Fine，thank you" 一起回给客户端。