TCP全称为"传输控制协议(Transmission Control Protocol)。人如其名,要对数据的传输进行一个详细的控制。
传输的数据控制（关注可靠与效率），可靠与效率成反比，越可靠效率越低。
TCP是综合考虑了两者，取的一个均衡:不是保证绝对意义的可靠，也不是绝对意义的效率最高
主机A发送数据给B之后,可能因为网络拥堵等原因,数据无法到达主机B;
如果主机A在一个特定时间间隔内没有收到B发来的确认应答,就会进行重发;
没有接收到ack应答包，可能是由于:(1)发送数据丢包。（2）ack应答丢包
解决办法：发送数据包重新发送。
超时时间如何确定，隔多长时间进行重传呢？
跟网络环境有关，是动态变化的。
- Linux中(BSD Unix和Windows也是如此),超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍.
- 如果重发—次之后,仍然得不到应答,等待2*500ms后再进行重传.
- 如果仍然得不到应答,等待4*500ms进行重传.依次类推,以指数形式递增.累计到一定的重传次数, TCP认为网络或者对端主机出现异常,强制关闭连接.
建立连接流程如下：
断开连接流程如下：
1. 双方连接状态为什么最后才是closed(已关闭)？
答：双方都要保证可靠的关闭连接。
2. 第2，3个数据报为什么没有合并？
答：第2个数据报，是系统内核返回的(不用程序写代码来发送)
第3个数据报，是程序调用close方法发送的服务端在关闭连接前，可能需要做一些其他工作。
是否可以合并：先放在缓冲区（可能是立即发，也可能不是)=>对应的，第三个数据报也是发送到缓冲区。
此时，如果第二个数据报还在缓冲区，就可能合并发送。
3. 服务端出现大量的close_wait，原因?
答：服务端没有执行 close方法，因为执行close方法才会发送第3个数据报。
4.客户端接收第3个数据报，状态为什么置为TIME_WAIT，而不是CLOSED？
答：客户端接收到第3个数据报，不能马上置为CLOSED。第4个数据报，可能出现丢包（服务端无法断开连接)服务端就会根据超时重传机制，重发第3个数据报此时客户端如果是CLOSED，就没法接收了。
5.客户端接收第3个数据报，状态时TIME_WAIT,需要等多久？
答：2MSL。1MSL是单个报文传输的最大时间。
作用：以并行的方式发送数据报，减少等待时间，提高效率。
窗口大小如何确定？
窗口大小：无需等待确认应答，而可以继续发送的数据报最大值。
滑动窗口大小：滑动窗口大小= min(流量窗口大小，拥塞窗口大小)
窗口滑动是如何滑动的？
发生丢包的情况：
背景：发送端发送速度如果快于接收端，程度读取速度，就可能导致接收缓冲区被打满，进而引起一系统丢包，重传再次丢包的问题。
背景:网络状态不明的情况下，贸然发送大量的数据报，就可能产生网络拥塞。类似发快递，不清楚交通状态，就贸然发送大批量的货物，可能导致交通阻塞。
- 发送开始的时候,定义拥塞窗口大小为1;
- 每次收到一个ACK应答,拥塞窗口加1;
- 每次发送数据包的时候,将拥塞窗口和接收端主机反馈的窗口大小做比较,取较小的值作为实际发送的窗
- 当TCP开始启动的时候,慢启动阈值等于窗口最大值;
- 在每次超时重发的时候,慢启动阈值会变成原来的一半，同时拥塞窗口置回1;
背景：接收端返回流量窗口代表接收缓冲区可用空间大小，如果立即返回，就不划算（立即返回的流量窗口大小就会比较小）
接收端返回的流量窗口（ack应答包有窗口大小字段），不是立即返回，而是等待一定时间，这样返回的流量窗口大小就可能更大
所以延迟应答是效率机制——延迟一定时间应答，效率就更高。
背景:不管是客户端还是服务端，每一端，即可以是发送端，也可以是接收端。不管客户端还是服务端，接收到数据后，返回的ack应答包(作为接收端)，可以和发送的数据报（作为发送端）合并在一起（捎带的方式)发送给对方。
应用层需要约定统一的协议:明确包和包之间的边界。没有明确边界，就会出现粘包问题。
站在传输层角度，TCP是一个一个报文过来的，按序号排好在缓冲区。而应用层角度，看到的只是一串连续字节数据。
传输层:如果基于tcp协议（面向字节流，没有关闭流，可以一直收发数据)
解决方案
UDP协议：因为是面向数据报的，不存在粘包问题。
| UDP | TCP |
|---|---|
| 无连接 | 有连接（三次握手、四次挥手） |
| 不可靠 | 可靠 |
| 面向数据报 | 面向字节流 |
| 缓冲区：只有接收缓冲区 | 有接收缓冲区和发送缓冲区 |
| 大小受限 | 大小不限 |
| 适用场景：实时性要求高，允许少量丢包。（早期QQ） | 适用场景：可靠性比较高的地方（文件传输） |
面向数据报：
应用层交给UDP多长的报文,UDP原样发送,既不会拆分,也不会合并;
用UDP传输100个字节的数据:
如果发送端调用一次sendto,发送100个字节,那么接收端也必须调用对应的一次recvfrom,接收100个字节;而不能循环调用10次recvfrom,每次接收10个字节。
面向字节流：
创建一个TCP的socket,同时在内核中创建一个发送缓冲区和一个接收缓冲区;
- 调用write时,数据会先写入发送缓冲区中;
- 如果发送的字节数太长,会被拆分成多个TCP的数据包发出;
- 如果发送的字节数太短,就会先在缓冲区里等待，等到缓冲区长度差不多了,或者其他合适的时机发送出去;
- 接收数据的时候,数据也是从网卡驱动程序到达内核的接收缓冲区;然后应用程序可以调用read从接收缓冲区拿数据;
- 另一方面, TCP的一个连接,既有发送缓冲区,也有接收缓冲区,那么对于这一个连接,既可以读数据,也可以写数据.这个概念叫做全双工
由于缓冲区的存在,TCP程序的读和写不需要一一匹配,例如:
- 写100个字节数据时,可以调用一次write写100个字节，也可以调用100次write,每次写一个字节
- 读100个字节数据时,也完全不需要考虑写的时候是怎么写的,既可以一次read 100个字节,也可以一次
read一个字节,重复100次;
在应用层，自己引入序列号，确认应答机制、超时重传机制等类似TCP的机制，实现可靠传输。
在应用层，自己写代码实现 引入序列号，确认应答机制、超时重传机制等类似TCP的机制，实现可靠传输。
