*一，TCP的服务：
TCP全双工的一对一通信，不能用于广播和多播。提供可靠的，面向连接的字节流服务 。
如何可靠的：
1.应用数据被分割成TCP认为最适合发送的数据块（在三次握手时，可协商MSS的大小，双方都通告自己期望的MSS，若有一方没有接收，默认536），防止IP层发生IP分片导致发送失败重传。
2.当TCP发送一个段后，会启动一个定时器，等待目的端确认收到，如果不能及时收到回复则重新发送。收到一个报文段后会回复一个确认。
3.校验和：TCP首部会记录数据校验和，以保证数据完整性，否则会请求发送方重发。
4.送达的TCP段（因为依赖IP段发送的）失序，则重新排序。IP数据报会发生重复，所以TCP接收端会丢弃重复的段。
5.TCP提供流量控制：(依赖滑动窗口)
1>流量控制就是让发送方的发生速率不要太快，要让接收方来的及接收，不然会找出数据溢出丢失。
2>滑动窗口：是一个缓冲区，若每一次发都要等上一次的确认后，则效率缓慢，故使用滑动窗口接收N可可接受的报文段。接收端将此窗口值放在 TCP 报文的首部中的窗口字段，传送给发送端。
滑动窗口实现面向流的可靠性：
1）最基本的传输可靠性来源于“确认重传”机制。
2）TCP的滑动窗口的可靠性也是建立在“确认重传”基础上的。
3）发送窗口只有收到对端对于本段发送窗口内字节的ACK确认，才会移动发送窗口的左边界。
4）接收窗口只有在前面所有的段都确认的情况下才会移动左边界。当在前面还有字节未接收但收到后面字节的情况下，窗口不会移动，并不对后续字节确认。以此确保对端会对这些数据重传。
滑动窗口实现面向流的可靠性：
1）最基本的传输可靠性来源于“确认重传”机制。
2）TCP的滑动窗口的可靠性也是建立在“确认重传”基础上的。
3）发送窗口只有收到对端对于本段发送窗口内字节的ACK确认，才会移动发送窗口的左边界。
4）接收窗口只有在前面所有的段都确认的情况下才会移动左边界。当在前面还有字节未接收但收到后面字节的情况下，窗口不会移动，并不对后续字节确认。以此确保对端会对这些数据重传。
*拥塞避免：
拥塞控制是防止传输数据的联络层网络出拥塞时数据大量丢失的情况。
拥塞避免主要包含以下2个内容：
（1）慢开始，拥塞避免：
1>在主机刚刚开始发送报文段时可先将拥塞窗口 cwnd 设置为一个最大报文段 MSS 的数值。
2>每收到一个对新的报文段的确认后，将拥塞窗口增加至多一个 MSS 数值。
3>用这样的方法逐步增大发送端的拥塞窗口 cwnd，可以使分组注入到网络的速率更加合理。
1.当 TCP 连接进行初始化时：
发送窗口：swnd = 1
慢开始阈值：ssthresh = 16
2.发送端收到 ACK1 （确认 M0，期望收到 M1）后，将 cwnd 从 1 增大到 2，于是发送端可以接着发送 M1 和 M2 两个报文段（指数增长）
3.接收端发回 ACK2 和 ACK3。发送端每收到一个对新报文段的确认 ACK，就把发送端的拥塞窗口加 1。现在发送端的 cwnd 从 2 增大到 4，并可发送 M4 ~ M6共 4个报文段。（指数增长）
4.当swnd >= ssthresh，swnd执行拥塞避免算法，swnd窗口按线性规律增长。 （加法增大）
5.当发送 超时，此时swnd = 24 ：
ssthresh = swnd/2 = 12；（乘法减小）
swnd = 1
6.重复地2步。
（2）快重传，快恢复：
1. 快重传：
发送端只要一连收到三个重复的 ACK 即可断定有分组丢失了，就应立即重传丢失的报文段而不必继续等待为该报文段设置的重传计时器的超时
2. 快恢复：
(1) 当发送端收到连续三个重复的 ACK 时，就重新设置慢开始门限 ssthresh。
(2) 与慢开始不同之处是 swnd 不是设置为 1，而是设置为 ssthresh + 3 * MSS。
(3) 若收到的重复的 ACK 为 n 个（n > 3），则将 cwnd 设置为 ssthresh + n * MSS。
(4) 若发送窗口值还容许发送报文段，就按拥塞避免算法继续发送报文段。
(5) 若收到了确认新的报文段的 ACK，就将 swnd 缩小到 ssthresh。
拥塞避免和流量控制的联侧重点：：
1.流量控制解决的只是过快的发送方的问题，思路也很简单，得到ACK确认来调整发送速率，对于未收到的包再重传。这里考虑的只是一组端到端的情况，所以有点理所当然，发送方发送速率过快，那就遏制一下这个发送方的发送速率。
2.拥塞避免是解决发送/介绍搜端之间的问题：：路由器等问题。
Q：滑动窗口和拥塞窗口都存在的原因：
A:滑动窗口协议是传输层进行流控的一种措施，接收方通过通告发送方自己的窗口大小，从而控制发送方的发送速度，从而达到防止发送方发送速度过快而导致自己被淹没的目的。发送方一开始便向网络发送多个报文段，直至达到接收方通告的窗口大小为止。当发送方和接收方处于同一个局域网时，这种方式是可以的。但是如果在发送方和接收方之间存在多个路由器和速率较慢的链路时，就有可能出现一些问题。一些中间路由器必须缓存分组，并有可能耗尽缓存。
*二，TCP首部：
1>TCP数据被封装在一个IP数据报中，IP首部20字节+TCP首部20字节+TCP数据。源/目的端口+IP数据包装中的源/目的IP地址确定一个连接。
2>序号：占4个字节，是本报文段所发送的数据项目组第一个字节的序号。在TCP传送的数据流中，每一个字节都有一个序号。
3> 确认序号：占4字节，是期望收到对方下次发送的数据的第一个字节的序号，也就是期望收到的下一个报文段的首部中的序号.（因为序号字段有32比特长，可以对4GB的数据进行编号，如许就可包管当序号反复应用时，旧序号的数据早已在收集中消散了）
4>数据偏移：TCP首部长度（TCP首部不固定大小）
5>标志位：
URG：紧急指针，次报文段需要尽快传送。
ACK：确认序号。
PSH：不用等缓存满就开始传送。
RET：重建立连接，情景：1.服务器端口未打开，2.请求超时，3.socket已经关闭了，4.异常关闭。
SYN：同步序号：发起连接。
FIN：断开连接。
6>窗口字段：发送大小。
7>校验和：覆盖了整个TCP报文段：：首部+数据。
8>紧急指针：URG=1时有效。
9>可选字段是最大报文段MSS，三次握手时第一个报文段中指明MSS大小。
*三，TCP连接与终止
1.三次握手进行连接：
1>客户发送一个SYN段指明打算连接服务器的端口，以及初始序号ISN。
2>服务器回复包含服务器ISN的SYN段，并将客户的ISN+1回复。
3>客户将序号设置为服务器的ISN+1对服务器的SYN确认。
2.四次挥手：
1>第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
2>第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。
3>第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
4>第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。
Q: TCP与UDP的区别？
A:
TCP与UDP基本区别：
1.基于连接与无连接
2.TCP要求系统资源较多，UDP较少；
3.UDP程序结构较简单
4.流模式（TCP）与数据报模式(UDP);
5.TCP保证数据正确性，UDP可能丢包
6.TCP保证数据顺序，UDP不保证
UDP应用场景：
1.面向数据报方式
2.网络数据大多为短消息
3.拥有大量Client
4.对数据安全性无特殊要求
5.网络负担非常重，但对响应速度要求高
具体编程时的区别
1.socket()的参数不同
2.UDP Server不需要调用listen和accept
3.UDP收发数据用sendto/recvfrom函数
4.TCP：地址信息在connect/accept时确定
5.UDP：在sendto/recvfrom函数中每次均 需指定地址信息
6.UDP：shutdown函数无效
Q:TIME_WAIT状态如何产生？
A:首先调用close()的一方在发送左后一个ACK之后进入TIME_WAIT状态，保持2MSL（数据包在网络上最大生存时间）后才会进入到初始状态。期间内该端口不能再次使用。
Q:TIME_WAIT产生原因？？
A:
1>为实现TCP全双工通信的可靠释放，假设请求关闭方最后一个ACK在网络中丢失，被动方会重发FIN，所以主动方得维护这条连接。
2>为使旧数据包在网络上因过期而消失。
Q:服务器出现大量的TIME_WAIT状态原因，解决方案？？
A:短通信中，由服务器发起主动关闭的连接多。
解决：保证客户端主动发起关闭，或者不进入TIME_WAIT状态。
IP分片：：
数据链路层用MTU（最大传输单元一般大小1500字节）来限制传输数据包的大小，当发送的IP数据报超过了MTU，则进行IP分片<源主机会ip分片，路由器也能分片>重组则是发生在目的端的链路层。
避免IP分片：：
IP层没有重传机制，若丢失一片，则传输层需要衷心发送整个包，所以会降低发送成功率。
对于TCP而言：在三次握手时已经互通MSS了，所以避免了IP分片，
对于UDP而言：限制每个包的大小小于1472（MTU-UDP首部8-ip首部20=1472）