发送接收缓冲区滑动窗口
发送窗口与接收窗口关系
TCP是双工的协议，会话的双方都可以同时接收、发送数据。TCP会话的双方都各自维护一个“发送窗口”和一个“接收窗口”。其中各自的“接收窗口”大小取决于应用、系统、硬件的限制（TCP传输速率不能大于应用的数据处理速率）。各自的“发送窗口”则要求取决于对端通告的“接收窗口”，要求相同。
名词解释
MTU:maximum transmission unit，最大传输单元，由硬件规定，如以太网的MTU为1500字节。指的是ip层包括ip头和data最大为1500字节。超过了则ip层要进行分片。一般针对udp协议，tcp不会发生。对于TCP协议而言，这个协议是面向连接的协议，对于TCP协议而言它非常在意数据包的到达顺序以及是否传输中有错误发生。所以有些TCP应用对分片有要求—不能分片（DF）。
MMS:maximum segment size，最大分节大小，为TCP数据包每次传输的最大数据分段大小，一般由发送端向对端TCP通知对端在每个分节中能发送的最大TCP数据。MSS值为MTU值减去IPv4 Header（20 Byte）和TCP header（20 Byte）得到，实际情况可能还要减去TCP的可选项。
TTL：(Time To Live)，表明是数据报在网络中的寿命,由发出数据报的源点设置这个字段,其目的是防止无法交付的数据报无限制地在因特网中兜圈子，因而白白消耗网络资源，每经过一个路由器时，就把TTL值减1。当TTL值为0时，就丢弃这个数据报，工作在ip层。
RTO:（Retransmission TimeOut）即重传超时时间。
RTT:（Round Trip Time）由三部分组成：链路的传播时间（propagation delay）、末端系统的处理时间、
路由器缓存中的排队和处理时间（queuing delay）。其中，前两个部分的值对于一个TCP连接相对固定，路由器缓存中的排队和处理时间会随着整个网络拥塞程度
的变化而变化。所以RTT的变化在一定程度上反应了网络的拥塞程度。
cwnd:发送端窗口( congestion window )
rwnd:接收端窗口（receiver window）
流控制：端到端，接收端的应用层处理速度决定和网速无关，由接收端返回的rwnd控制
拥塞控制： 发送端主动控制控制cwnd，有慢启动（从cwnd初始为1开始启动，指数启动），拥塞避免（到达ssthresh后，为了避免拥塞开始尝试线性增长），快重传（接收方每收到一个报文段都要回复一个当前最大连续位置的确认，发送方只要一连收到三个重复确认就知道接收方丢包了，快速重传丢包的报文，并TCP马上把拥塞窗口 cwnd 减小到1），快恢复（直接从ssthresh线性增长）。
发送方窗口的上限值 = Min [ rwnd, cwnd ]
当rwnd < cwnd 时，是接收方的接收能力限制发送方窗口的最大值。
当cwnd < rwnd 时，则是网络的拥塞限制发送方窗口的最大值。
由于对于每一个TCP的SOCKET来说，都有一个发送缓冲区和接受缓冲区与之对应，所以这里只做单方向jiāo流，不做互动，在recv端不send,在send端不recv。细细揣摩其中的含义。
一、recv端
在监听套接字上准备accept，在accept结束以后不做什么操作，直接sleep很久，也就是在recv端并不做接受数据的操作，在sleep结束之后再recv数据。
二、send端
通过查看本系统内核默认的支持的最大发送缓冲区大小，cat/proc/sys/net/ipv4/tcp_wmem，最后一个参数为发送缓冲区的最大大小。接受缓冲区最大的配置文件在tcp_rmen中。
将套接字设置为阻塞，一次发送的buffer大于最大发送缓冲区所能容纳的数据量，一次send结束，在发送返回后接着答应发送的数据长度
测试结果：
阶段一：
接受端表现：在刚开始发送数据时，接收端chǔ于慢启动状态，滑动窗口大小越来愈大，但是由于接收端不chǔ理接受缓冲区内的数据，其滑动窗口越来越小（因为接受端回应发送端中的win大小表示接受端还能够接受多少数据，发送端下次发送的数据大小不能超过回应中win的大小），最后发送端回应给接受端的ACK中显示的win大小为0，表示接收端不能够再接受数据。
发送端表现：发送端一直不能返回，如果接受端一直回应win为0的情况下，发送端的send就会一直不能返回，这种僵局一直持续到接收端的sleep结束。
原因分析：首先需要明白几个事实，阻塞式I/O会一直等待，直达这个操作完成；发送端接受到接收端的回应后才能将发送缓冲区中的数据进行清空。
在接收端不recv，那么接收端的接受缓冲区内会一直有数据，接受缓冲区满，导致滑动窗口为0，导致发送端不能发送数据。但是send操作为何不能反悔呢？send操作只是将应用缓冲区的数据拷贝到发送缓冲区，但是发送缓冲区的数据并没有完全得到接收端的ACK回应，所以暂时不能将发送缓冲区中的数据丢弃，导致发送缓冲区的被填满，这样应用层中的数据也就不能拷贝到内核发送缓冲区内，也就会一直阻塞在这里，直到可以继续讲应用层的数据拷贝到发送缓冲区中，何时触发这个操作呢？等到发送端回应win大于0时才有这样的操作。
阶段二;
接受端：在sleep结束以后，开始调用recv系统调用。这个时候接受端的滑动窗口又开始大于零。那么这样就唤醒了发送端继续发送数据。
发送端：发送端接受到接收端win大于0的回应，这个时候发送端又可以将应用层buffer中的数据拷贝到内核的发送缓冲区中。
原因分析：由于接受端调用recv将内核接受缓冲区的数据拷贝到应用层中，这样滑动窗口又大于0了所以激发了发送端继续发送数据，由于发送端可以发送数据了，内核协议栈便将发送缓冲区中的数据发送给接受端，这样发送缓冲区又有空间了，那么send操作就可以将应用层的数据拷贝到发送缓冲区了！这样的操作一直保持到send操作返回，这样代表着将应用层的数据全部拷贝到发送缓冲区内，但不代表将数据发送给对端。发送给对端成功的标志是接受到对端的ACK回应，这个时候发送端才可以将发送缓冲区的数据丢弃。不丢弃的原因是时刻准备重发丢失/出错的数据！
Ps: TCP通信为了保证可靠xìng，每次发送的数据都需要得到对方的ACK才确认对方收到了(仅保证对方TCP接收缓冲收到 数据了，但不保证对方应用程序取到数据了)，这时如果每次发送一次就要停下来等着对方的ACK消息，显然是一种极大的资源浪费和低下的效率，这时就有了滑动窗口的出现。
发送方的滑动窗口维持着当前发送的帧序号，已发出去帧的计时器，接收方当前的窗口大小(由接收方ACK通知，大体等于接收缓冲大小-未chǔ理的消息包)，接收方滑动窗口保存的有已接收的帧信息、期待的下一帧的帧号等，至于滑动窗口的具体工作原理这里就不说了。
一 个socket有两个滑动窗口(一个sendbuf、一个recvbuf)，两个窗口的大小是通过setsockopt函数设置的，现在问题就出在这里， 通过抓包显示，设置的窗口大小没有生效，最后排查发现setsockopt函数是后来加上的，写到了listen函数的后面，这样每次accept出的 socket并没有继承得到主socket设置的窗口大小，无语啊……
解决办法：setsockopt函数提前到listen函数之前，这样在服务器程序启动监听前recvbuf就已经有了，accept后的链接得到的就是recvbuf了，启动程序运行，抓包显示窗口已经是指定的大小了。
一、TCP的滑动窗口大小实际上就是socket的接收缓冲区大小的字节数
二、 对于server端的socket一定要在listen之前设置缓冲区大小，因为，accept时新产生的socket会继承监听socket的缓冲区大 小。对于client端的socket一定要在connet之前设置缓冲区大小，因为connet时需要进行三次握手过程，会通知对方自己的窗口大小。在 connet之后再设置缓冲区，已经没有什么意义。
三、由于缓冲区大小在TCP头部只有16位来表示，所以它的最大值是65536，但是对于一些情况来说需要使用更大的滑动窗口，这时候就要使用扩展的滑动窗口，如光纤高速通信网络，或者是卫星长连接网络，需要窗口尽可能的大。这时会使用扩展的32位的滑动窗口大小。
-1. TCP协议的两端分别为发送者A和接收者B，由于是全双工协议，因此A和B应该分别维护着一个独立的发送缓冲区和接收缓冲区，由于对等性（A发B收和B发A收），我们以A发送B接收的情况作为例子；
-2. 发送窗口是发送缓存中的一部分，是可以被TCP协议发送的那部分，其实应用层需要发送的所有数据都被放进了发送者的发送缓冲区；
-3. 发送窗口中相关的有四个概念：已发送并收到确认的数据（不在发送窗口和发送缓冲区之内）、已发送但未收到确认的数据（位于发送窗口之中）、允许发送但尚未发送的数据以及发送窗口外发送缓冲区内暂时不允许发送的数据；
-4. 每次成功发送数据之后，发送窗口就会在发送缓冲区中按顺序移动，将新的数据包含到窗口中准备发送；
如果B已经告诉A自己的缓冲区已满，于是A停止发送数据；等待一段时间后，B的缓冲区出现了富余，于是给A发送报文告诉A我的rwnd大小为400，但是这个报文不幸丢失了，于是就出现A等待B的通知||B等待A发送数据的死锁状态。为了处理这种问题，TCP引入了持续计时器（Persistence timer），当A收到对方的零窗口通知时，就启用该计时器，时间到则发送一个1字节的探测报文，对方会在此时回应自身的接收窗口大小，如果结果仍未0，则重设持续计时器，继续等待。
单个发送字节单个确认，和窗口有一个空余即通知发送方发送一个字节，无疑增加了网络中的许多不必要的报文（请想想为了一个字节数据而添加的40字节头部吧！），所以我们的原则是尽可能一次多发送几个字节，或者窗口空余较多的时候通知发送方一次发送多个字节。对于前者我们广泛使用Nagle算法，即：
*1. 若发送应用进程要把发送的数据逐个字节地送到TCP的发送缓存，则发送方就把第一个数据字节先发送出去，把后面的字节先缓存起来；
*2. 当发送方收到第一个字节的确认后（也得到了网络情况和对方的接收窗口大小），再把缓冲区的剩余字节组成合适大小的报文发送出去；
*3. 当到达的数据已达到发送窗口大小的一半或以达到报文段的最大长度时，就立即发送一个报文段；
对于后者我们往往的做法是让接收方等待一段时间，或者接收方获得足够的空间容纳一个报文段或者等到接受缓存有一半空闲的时候，再通知发送方发送数据。
