TCP与UDP深度理解
1.UDP协议
通过上篇博客，我们可以清楚的了解到UDP协议是无连接，不可靠传输，面向数据报，全双工。并且，所谓的UDP/TCP/IP协议，其实都是通过报头加上载荷（应用层数据包）来构成的。在此基础上，现在让我们更加深层了解它吧
1.1UDP协议格式
下图是UDP协议格式： 
1.2UDP格式解析
其实这个协议格式也就是UDP报头，而其中16位源端口号指的是表明发送方是那个程序发出来的。与他相对应的是16位目的端口号，这个指的是接收方交给哪个程序进行处理。为了好理解点，我们可以理解源端口号指的是自己，目的端口号指得是别人。
16位UDP长度指的是这个报头的长度，它最长的长度是64KB，当UDP携带一个大于64KB的数据，那么就会发生截断。
为了解决这个问题，有两种方案。方案一是在应用层进行拆包组包，例如：一个广告正常讲要返回10条，但太长了。因此，它会在应用层将它拆成两个UDP数据报，各自返回五条。但因为这个网络传输过程中，可能会出现数据丢失的情况。因此要进行核验，也因此开销巨大。方案二是使用TCP。
16位UDP校验和是用来验证传输数据是否出错。它这里的原理是将数据的字节代入公式中，得出一个校验和，当数据传到接收方时，它会再次将数据的字节代入公式，并用此结果与前面的校验和进行比较。相同就说明数据传输没有错误
1.3端口创建
当我们在设置端口号时，我们会在1024~65535进行选择，而0~1023属于知名端口号，一般不使用。像mysql的端口是3306，redis是6379。并且要知道，一个进程可以绑定多个端口，但一个端口不能绑定多个线程。
打个比方，当你在使用手机聊天软件（一个进程)时，可能需要同时处理两种数据，文字消息（1345端口）和视频电话（1453端口）。此时，软件就会绑定这两个端口。但如果此时有一个端口，但绑定到多个进程（如游戏软件和聊天软件）中，这时他就会有歧义，不知道应该分配给谁。
2.TCP协议
2.1TCP协议格式
TCP协议格式会较为复杂，下图是TCP协议格式：
2.2TCP格式解析
首先先明确的是，16位源端口和16位目的端口还有16位校验和都是和UDP功能一样的
其次4位首部长度指的是TCP报头长度，换句话讲，就是TCP的报头长度不固定。因为报头的前五行已经是固定的，不能发生改变（占20字节）。所以选项就是配合着来进行改变长度。保留位是用来预防TCP报头协议以后有新功能，需要添加而设立的，可以理解为预定着位置先。
32位序号是针对传输的数据进行编号和32位确认序号是给ack报文使用的，用来关联当前ack哪个是应答哪个数据的
16位窗口大小是用来确定窗口大小的，它只在ACK中发挥作用，6个标志位就像TCP的指令合集，16位紧急指针（与URG和PSH有关）是让这个数据进行插队，让后面的数据先被读取，现在已经不用了
2.3TCP的核心机制
2.3.1确认应答
这个是TCP实现可靠传输的核心机制。它的原理就是通过32位序号发送方先发送数据给接收方，然后接收方收到后再用32位确认序号返回ack给发送方，告诉发送方的信息已传达，如下图所示：
但因为在网络传输信息的过程中，可能会出现后发先至的情况。所以，TCP就给信息进行编号的措施，并且这个编号是从某个数字开始，并依次向后递增的。然后还有确认填写方式是收到数据的最后一个字节序号再 +1 ，值得注意的是，每次的连接TCP的序号都不同，并且序号差别很大大，具体关系可以参考下图：
2.3.2超时重传
在传输中会出现两种情况，发送时数据丢失或者是返回ack时丢失，如图：
详细讲下第二种，正常来讲当传输一个数据给对方时，发送方系统会将数据储存到一个缓冲区（备份）并且开始等待ack，等对方收到数据后返回ack时，发送方收到ack后删除备份，程序就结束。但若此时，当ack没有返回，程序就会误以为数据并没有到达对方，重新发送在缓冲区数据。当重复的数据到达对方时，对方会对数据进行去重，保留旧数据，再次返回ack。这一操作解决了数据的“可靠性”的问题
如果第一次没有收到，就会重传，并且等待时间会一次比一次更长。不过当多次重传达到一定的个数，发送方认为是网络故障从而打断当前TCP连接。
2.3.3连接管理
这里分成两种连接：建立连接和断开连接。
(1)三次握手
建立连接的流程叫做“三次握手”，也可以成为四次握手（因为他们俩是由操作系统内核来控制的，而且ack和syn合并能提高效率）。也就是说当握手完才能建立连接，如图所示：
三次握手的作用是，首先先初步验证链路是否畅通，为后续持续传输数据作保障。同时也在验证通信双方的接收和发送能力是否正常
(2)四次挥手
断开连接的流程叫做四次挥手
不过这里的不能被省略，因为ACK是内核控制，而FIN的返回时机是由应用程序控制的。是程序调用socket.close才会触发FIN
(3)TCP状态
1、LISTEN，这个状态是服务器特有状态，也就是服务器启动，socket关联好端口号后的状态，能理解成时刻准备着的状态
2、ESTABLISHED这个表示已经建立完成，接下来可以进行网络通信了
3、SYN_SENT和SYN_RCVD是握手才有的，短暂的，属于中间状态
4、FIN_WANT 1和FIN_WANT 2是挥手才有的，也是短暂的，属于中间状态
5、CLOSE_WAIT是断开连接的时候，收到FIN的一方会进入的状态，也就是说一收到FIN，就立即进入这个状态。直到它主动发出FIN才会消失。能理解成等待close方法
6、TIME_WAIT是主动断开的一方会进入的状态，作用是等待一段时间，目的是为了防止最后一个ack丢包，一般来说默认值是一分钟
2.3.4滑动窗口
这个是用来一次传输多组数据，不用等待ACK，就犹如几束光照入每个窗口。这能提高传输的效率。但值得留意的是，每次传输的数据要有限制，不能无限的传输。
当传输的途中出现丢数据的情况，它会进行处理，过程是当1001~2000的数据丢了，发送方给接收方发送2001~3000的数据，在接收方收到后，ACK返回的是1001，并且持续多次。然后发送方就意识到1001丢了，然后重新进行发送。待发送完之后，ACK便跳到对应的序号且加一，如下图：
不过当ack丢了的情况，他不会进行处理，因为后续的ACK足以说明前面的数据已经到达（因为序号是连续的）
若传输数据即将到底，滑动窗口的速度会逐渐减慢，这样就能有效的解决最后一个ACK丢的问题
结论：窗口越大，批量传输的数据越多，传输的效率越高
2.3.5流量控制
这个是用来保证可靠性的，如果发送方发送数据的数据快于接收方读取数据的速度，那么数据就会在缓冲区中进行堆积，当缓冲区满了之后，数据会被丢失。因此，就要用到流量控制了。
它的原理是接收方通过衡量接收缓冲区的剩余大小，然后再通过返回ACK（16位窗口大小）通知给发送方来进行调整。当缓冲区满了，发送方会周期性发送一个空载荷的窗口探测包，为了触发ACK得到一个新的窗口大小的值
2.3.6拥塞控制
这个是依据通信路径的处理能力来进行调整的，与流量控制差不多。不同的是这个是针对网络中间节点，它的原理是，先以缓慢速度进行传递，以指数性加速（增大窗口大小），当窗口达到阈值，以线性增长，直到丢包。然后再减小速度（减小窗口大小，回到丢包位置窗口的1/2），继续线性增长。大概如下图：
2.3.7延时应答
这个能提高传输效率，通俗讲就是等待，它的原理是，一般发送方发送一个数据给接收方，接收方不会立即应答，而是等待几百毫秒后才应答，这样的好处是能预防此信息后还有一条信息。
比如你收到朋友两条消息，不是看一条就立马回一条 “收到了”，而是等个几秒钟，看看有没有第三条，或者自己正好也要给对方发消息 —— 如果有，就直接在回复的消息里顺带说一句 “你前面两条我都看到了”，省得单独发两个 “收到”。
就像下图，1~1000和1001~2000的时间间隔太短了，TCP会延时应答，发送ACK为2001给发送方
2.3.8捎带问答
这个一般是配合延时应答而进行的，他通俗来说就是顺手的事，它的工作原理是赌接收方在延时应答的的时候会有响应，然后能顺带将ACK给传输给发送方
2.3.9面向字节流
指的是面向字节流时，会出现粘包的问题。所谓的粘包就是在多个数据包中，TCP不知道在哪个是属于一个数据包，从而导致数据出错。
解决的方法是通过分隔符进行提醒或者是在数据包前写好这个数据的大小，从而解决粘包问题
只要时面向字节流，就会有这种问题，不过现在的框架已经解决了这个问题
2.3.10异常情况
TCP的异常情况分成四个：进程崩溃、主机关机（正常流程关机）、主机关机（掉电）和网线断开
先说第一个进程崩溃，这个指的是当进程退出了，操作系统会对程序进行释放，等价于close。就好比客户端没了，但连接还在，所以依旧能进行四次挥手
第二种正常流程关机，和上面一样，依旧会触发close，依旧能四次挥手。不过特殊的是，他有可能还没有完全挥完就已经关机了。面对这种情况，接收方会一直重传FIN（因为没有收到ACK），多次无果后，他会进行单方面断连
第三种属于突然断电，两方都来不及挥手的情况。不过，这个也有两种情况，一种是接收方掉电，那么此时发送方就会重传，无果后，发送复位报文（RST），放弃连接。另一种是发送方掉电，此时，接收方不清楚知道发送方是掉了还是在等待，因此会周期的发送心跳包（空载荷报文）给发送方。当心跳包过去之后接收方没有收到ACK，说明发送方掉了。于是接收方就断开连接
第四种断网情况，分成两种，一种就是发送方断网，那么处理的方法和突然断电的发送方措施一样；另一种就是接收方断网，那么处理了方法就和发送方断电的措施一样