一. UDP协议
UDP协议端格式
由上图可以看出，一个UDP报文最大长度就是65535.
• 16位长度，表示整个数据报（UDP首部+UDP数据）的最大长度（注意，这里的16位UDP长度只是一个标识这个数据报长度的字段，并不是这个数据报传输的数据）
• 如果校验和出错，就会直接丢弃。
校验和 ：通过网线传输时，电信号使用高低电平来表示0和1.。但是，如果外部环境干扰，就有可能导致低电平->高电平，高电平->低电平，造成比特翻转=>数据就传输错了。校验和就是通过数据报中的数据内容通过计算得到的。值得注意的是**：如果校验和不对，此时你的数据一定不对，如果校验和对，但是数据也有一定概率是错误的。**
面向数据报：应用层交给UDP长的报文，UDP原样发送，既不会拆分，也不会合并。
用UDP传输100个字节的数据报：
如果一次发送端发送100个字节，那么接收端也必须一次接收100个字节；而不能循环10次接收，每次接收10个字节。
缓冲区：UDP只有接收缓冲区，没有发送缓冲区
UDP没有真正意义上的发送缓冲区，发送的数据会直接交给内核，由内核将数据传给网络层协议进行后续的传输动作；
DUP具有接收缓冲区，但是这个接收缓冲区不能保证收到的DUP报的顺序和发送DUP报的顺序一致；如果缓冲区满了，再到达的DUP数据就会被丢弃；
二. TCP协议
TCP协议段格式：
2.1 TCP原理
2.1.1 确认应答机制
TCP 将每个字节的数据都进行了编号。即位序列号。
发送方的序号为最后一个字节的编号，确认序号为无意义的数据；
接收方的序号和发送方的序号无关，确认序号为接收数据的序号+1。
（在接收缓冲区中，优先级队列通过序号来确定数据的发送先后顺序 ）
接收方就可以通过ack的确认序号，告诉发送方哪些数据已经收到了。
2.1.2 超时重传机制
主机A发送数据给B之后,可能因为网络拥堵等原因,数据无法到达主机B;
如果主机A在一个特定时间间隔内没有收到B发来的确认应答,就会重发。
但是，主机A未收到B发来的确认应答，也可能是因为主机B收到了数据，但是ACK丢失了；
因此若ACK丢失了，主机B会收到很多重复数据。那么TCP协议需要能够识别哪些包是重复的包，并且把重复的丢弃掉。这时候我们就可以利用前面提到的序号来达到去重的效果。
超时重传后，重复发送的数据报仍可能会丢失，TCP为了保证无论在任何环境下都能比较高性能的通信，因此会动态的计算这个最大超时时间。
如果重发一次，仍得不到应答，TCP就会将这个超时时间延长后再重发，在不停的延长超时时间后，当累积到一定的重传次数后,TCP就会重置连接，如果重置连接失效，TCP就会关闭连接，放弃网络通信。
2.1.3 连接管理机制（三次握手，四次挥手）
建立连接：三次握手
握手指的是通信双发，进行一次网络交互，相当于客户端和服务器之间，通过三次交互，建立了连接关系。
syn称为同步报文段。意思就是一方要向另一方，申请连接。
在报文头部中有6个特殊的比特位，如果设为1，则表示特定含义。
其中第二位，是ACK，如果这一位为1，表示当前TCP数据报是一个应答报文；
其中第五位，是SYN，如果这一位为1，表示当前TCP数据报是一个同步报文；
如果一个TCP数据报，第二位和第五位都是1，则当前这个报文时SYN+ACK
三次握手这个过程，本质上时投石问路，验证了客户端和服务器，各自的发送能力和接收能力是否正常
断开连接：四次挥手
FIN：结束报文段
四次挥手中的ack和fin是否可以合并？
在三次握手中，ack和syn时同一时刻触发的（都是内核来完成的）
四次挥手，ack和fin则是在不同时机触发的。
ack是内核完成的，会在收到fin的时候第一时间返回
fin则是应用程序代码控制的。在调用到socket的close方法时候才会出发fin
javafinally{ //thread.sleep(1000); socket.close(); }这个close的执行时机，可能是立即，也可能是隔很久，却决于你的代码怎么写。
如果立即 close，趁着刚才ack还没发呢，这里就可以合并，如果是隔很久再close，此时fin就只能单独发了。
注：这里的close只是进程关闭了，但是连接（连接是内核维护的）还在，客户端发送的ack，服务器仍然可以收到。
2.1.4 滑动窗口(效率机制)
对于每一个发送的数据段,都要给一个ACK确认应答,收到ACK后再发送下一个数据段。.由于这样的一收一发的方式性能较低，那么我们一次发送多条数据，就可以大大的提高性能。（其实是将多个段的等待时间重叠在一起了。
**•**窗口大小指的是无需等待应答而可以继续发送数据的最大值.上图的窗口大小就是4000个字节(4个段)。
• 发送前四个段的时候，不需要等待任何ACK，直接发送。
• 操作系统内核为了维护这个滑动窗口，需要开辟发送缓冲区来记录当前还有哪些数据没有应答；只有确认应答过的数据，才能从缓冲区删掉。
**•**窗口越大，则网络的吞吐率就越高。
如果出现了丢包的情况，如何重传？分两种情况：
**情况一：**数据包已经抵达，ACK被丢了。
这种情况下，部分ACK丢了并不要紧，因为可以通过后续的ACK进行确认。如果1001的 ACK没有接收到，收到了2001的ACK，那么就说明已经接收到了2001以前的数据。
**情况二：**数据包直接丢了。
**•**当某一段报文丢失之后，发送端会一直收到1001这样的ACK，就像是在提醒发送端"我想要的是"1001"一样；
**•**当发送端主机连续收到三次同样的"1001"这样的应答，就会将对应的数据1001~2000重新发送
**•**这个时候接收端收到了1001之后，再次返回的ACK就是7001了，因为2001~7000接收端其实之前就已经收到了，被放到了接收端操作系统内核的接收缓冲区中。
2.1.5 流量控制（安全机制）
接收端处理数据的速度是有限的。如果发送端发送的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送，就会造成丢包，继而引起丢包重传等一些列连锁反应。
因此TCP支持根据接收端的处理能力，来决定发送端的发送速度。这个机制就叫做流量控制
• 接收端将自己可以接收的缓冲区大小放入TCP首部中的"窗口大小"字段，通过ACK端通知发送端，此时发送端就可以根据这个窗口大小来批量发送这些数据了。
• 接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端；
• 发送端接收到了这个窗口之后，就会减慢自己的发送速度
• 如果接收端缓冲区满了，就会将窗口设置为0；这时发送方就不再发送数据，但是仍需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。
上述过程是把返回的窗口大小，当作实际的窗口，实践中可能会有出入。
发送方的窗口大小=min(流量控制,拥塞控制)。
2.1.6 拥塞控制（安全机制）
虽然TCP有了滑动窗口这个大杀器,能够高效可靠的发送大量的数据.但是如果在刚开始阶段就发送大量的数据,仍然可能引发问题.
因为网络上有很多的计算机,在传输的过程中,需要经历许多的节点,可能当前的网络状态就已经比较拥堵了,但是此时在不清楚当前网络状态下,贸然发送大量的数据,是很有可能引起雪上加霜的.于是,不管在客户端与服务器之间是经历怎样的路径,把这个路径当做黑盒一样的东西,每次发送不同数量的请求,来试验出最佳的发送窗口.
TCP引入 慢启动 机制,先发送少量的数据,探探路,摸清当前的网络拥堵状态,再决定按照多大的速度传输数据
• 发送开始的时候,定义拥塞窗口大小为1
• 每次收到一个ACK应答,拥塞窗口加1
• 每次发送数据包的时候,将拥塞窗口和接收端主机反馈的窗口大小作比较,取较小的值作为实际发送的窗口
为了让拥塞窗口不增长的那么快,变引入了一个叫做慢启动的阈值,当拥塞窗口超过这个阈值的时候,不再按照指数的方式增长,而是按照线性方式增长
• 当TCP开始启动的时候,慢启动阈值等于窗口最大值;
• 在每次超时重发的时候,慢启动阈值会变成原来的一般,同时拥塞窗口重置回1.
2.1.7 延迟应答
如果接受数据的主机立刻返回ACK应答,这时候返回的窗口肯能比较小.
• 假设接收缓冲区为1M,一次收到了500k的数据,如果立刻应答,返回的窗口就是500k
• 但实际上可能处理端处理的速度很快,10ms之内就把500k的数据从缓冲区消费掉了
• 在这种情况下,接收端处理还远没有达到自己的极限,即使窗口再放大一些,也能处理过来
• 如果接受端稍微等一会再应答,比如等待200ms再应答,那么这个时候返回的窗口大小就是1M
窗口越大,网络吞吐量就越大,传输效率就越高.我们的目标是在保证网络不拥塞的情况下尽量提高传输效率.
但是并不是所有的包都可以延迟应答
**•**数量限制:每隔N个包就应答一次;
**•**时间限制:超过最大延迟时间就应答一次
具体的数量和超时时间,操作系统不同也有差异;一般N取2,超时时间取200ms(根据业务需求可自定义)
2.1.8 捎带应答
在延迟应答的基础上,我们可以发现,很多情况下,客户端服务器在应用层也是一发一收的.意味着客户端给服务器说了"How are you" , 服务器中程序处理过请求后也会给客户端返回一个"Fine,thank you" , 那么这个时候ACK就可以搭顺风车,和服务器回应的"Fine, thank you" 一起返回给客户端
上述ACK是内核收到数据报后直接返回的,Fine....是应用程序,通过write写的数据,通过一系列代码执行到才返回,这俩时机本来是不同的.但是延时应答,使此时的ACK 就可能稍等一会再发送就很有可能和response 合并成一个数据报.四次挥手,有可能是三次挥手,就是捎带应答起到的效果.
2.2 粘包问题
在TCP协议头中，没有如同UDP一样的"报文长度"这样的字段，但是有一个序号这样的字段，站在传输层的角度，TCP是一个一个报文过来的。按照序号放在缓冲区中。站在应用层的角度，看到的只是一串连续的字节数据。那么应用程序看到了这么一连串的字节数据，就不知道从哪个部分开始到哪个部分结束，是一个完整的数据包。
如何解决粘包问题？归根结底就是一句话，明确两个包之间的边界。
**•**对于定长的包，保证每次都按照固定大小读取即可；例如上面的Request结构，是固定大小的，那么就从缓冲区从头开始按sizeof(Request) 依次读取即可
**•**对于变长的包，可以定义分隔符，来区分包（应用层协议，是程序员自己来定的，只要定义保证分隔符不和正文冲突即可）
• 对于变长的包，还可以在包头的位置，约定一个包总长读的字段，从而知道了包的结束位置
对于UDP协议来说，是否也存在"粘包问题"？
• 对于UDP，如果还没有上层交付数据，UDP的报文长度仍然在。同时，UDP是一个一个把数据交付给应用层。就有很明确的数据边界。
• 站在应用层的角度，使用DUP的时候，要么收到完整的UDP报文，要么不收，不会出现"半个"的情况。
2.3 TCP异常情况
2.3.1 进程关闭/进程崩溃
进程没了，socket 是文件，随之被关闭，虽然进程没了，但是连接还在，仍然可以继续四次挥手
2.3.2 主机关机（正常流程关机）
先杀死所有的用户进程，然后就和进程关闭一样。
虽然可以出发四次挥手，如果能够在关闭之前完成更好。
如果没有发完，比如，对方发的 fin 过来了，咱们没来得及ack就关机了，此时对端就会重传fin,重传几次之后，发现都没有ack,尝试重置连接，如果还不行，就直接释放连接。
2.3.3 主机掉电（把电源）
瞬间机器就关了，来不及进行任何挥手操作。此时分两种情况：
1）对端是发送端
对端就会收不到ack=>超时重传=>重置连接=>释放连接
2）对端是接收端
对端是没法立即知道，你这边是还没来得及发新的数据，还是直接没了。即使发送端没有写入操作，TCP自己也内置了一个保活机制"心跳包"。虽然是接收端，但是接收端会定期给发送端发送一个心跳包（ping),正常情况下就会返回一个(pong)，如果每个 ping 都有及时的 pong，这个时候就说明当前对端的状态良好，如果 ping 过去之后，没用 pong ，说明心跳没了，这边怕是打概率挂了（pong也有概率丢的，因此会连续几次都丢了才会判定连接断开）。
注：发送方也是有心跳包的，但是通过对方返回的ack来判定会更快一些。