UDP和TCP协议详解
⼀. 引⾔
⽹络协议是每个程序员都要掌握的基础知识,⼲啥都离不开⽹络，就算在家⾥新买了个路由器不是吗，同事连不上⽹，你的⼥朋友⼿机没有⽹看剧了正看到⾼潮部分，到那时候你打开百度......那嫌弃的你的眼神仿佛在说，就这?程序员连个⽹都不会修?以上都是臆想，以实际为准.虽然看完本⽂章，你还是需要去百度怎么修复⽹络问题，但是你已经知道为什么会出现这种问题了!
⼆. UDP
UDP协议全称是⽤户数据报协议，在⽹络中它与TCP协议⼀样⽤于处理数据包，是⼀种⽆连接的协议.在OSI中，第四层传输层，处于IP协议的上⼀层UDP有不提供数据包分组，组装和不能对数据包进⾏排序的缺点，也就是说，当报⽂发送后,⽆法监控其是否完整安全到达的，就想⼀个坏掉了的⽔龙头，你不论怎么让他停⽌他都只会输出，也不管你的桶满没满，就像爱⼀样 特点
1. ⾯向⽆连接:
⾸先UDP是不需要和TCP⼀样在发送数据前进⾏三次握⼿建⽴连接的，想发数据就可以开始发送了.并且也只是主句报⽂的搬运⼯，不会对数据报⽂进⾏任何拆分和拼接操作
具体来说:
在发送端，应⽤层将数据传递给UDP协议,UDP只会给数据增加⼀个UDP头标识下UDP，然后就传递给⽹络层了
在接收端,⽹络层将数据传递给传输层,UDP只去除IP报头就传递给应⽤层，不会任何拼接操作LED路灯外壳
2. 有单播，多播,⼴播的功能
UDP不⽌⽀持⼀对⼀的传输⽅式，同样⽀持⼀对多，多对多，多对⼀的⽅式，也就是说UDP提供了单播，多播和⼴播的功能.
3. UDP是⾯向报⽂的
发送⽅的UDP读应⽤程序交下来的报⽂，在添加⾸部后就向下交付IP层.UDP对应⽤层交下来的报⽂，既不合并，也不拆分,⽽是保留这些报⽂的边界.因此，应⽤程序必须选择合适⼤⼩的报⽂4. 不可靠性
⾸先不可靠性体现在⽆连接上，通信不需要建⽴连接，想发就发，这样的情况肯定不可靠
并且受到什么数据就传递什么数据，并且也不会备份数据，发送数据也不会关⼼对⽅是否已经正确接收到数据了
再者⽹络环境时好时坏，但是UDP因为没有拥塞控制,⼀直会以恒定的速度发送数据，即使⽹络条件不好，也不会对发送数据进⾏调整.这样实现的弊端就是在⽹络条件不好的情况下会导致丢包，但是有点也很明显,⽐如电话会议等等最好就是UDP
5. 头部开销⼩，传输数据报⽂是很⾼效的.
因此UDP的头部开销⼩，只有⼋字节，相⽐TCP的⾄少⼆⼗字节要少得多，在传输数据报⽂时是很⾼效的
三. TCP/IP⽹络模型
计算机⽹络设备相互通信，双⽅必须基于相同的⽅法.⽐如如何探测到通信⽬标，由那⼀边先发起通信，使⽤哪种语⾔进⾏通信，怎样结束通信等规则都需要实现确定.不同硬件，操作系统之间的通信，所有的这⼀切都需要⼀种规则,⽽我们吧这种规则成为协议.
TCP/IP是互联⽹相关的各类协议的总称,⽐如:**TCP，UDP，IP，FTP，HTTP，ICMP，SMTP **等都属于 TCP/IP 族内的协议
⼤家⼀定知道OSI七层模型,TCP/IP概念模型是这样的
应⽤层：负责向⽤户提供应⽤程序.⽐如HTTP,FTP,Telnet,DNS,SMTP等
永久模板传输层：负责对报⽂进⾏分组和重组，并以TCP或UDP协议格式封装报⽂
⽹络层：负责路由以及把分组报⽂发送给⽬标⽹络或主机
链路层：负责封装和接缝IP报⽂，发送和接收ARP/RARP报⽂等
TCP
当⼀台计算机想要与另⼀台计算机通讯时，两台计算机之间的通信需要畅通且可靠，这样才能保证正确收发数据.例如当你收⽂件时候不希望收到的是⼀个损坏的⽂件，发过来的⼩电影是⽆法放映的，或者直接变成马赛克，当然也可能本来就有马赛克，这不是我们希望得到的，于是就⽤到了TCP
TCP协议全称是传输控制协议,，这是⼀种⾯向连接的，可靠的，基于字节流的传输层通信协议
TCP的连接过程
TCP报⽂也分为⾸部和数据两部分,⾸部默认情况下⼀般是20字节长度，但在20字节长度，但在⼀些请
求情况下，会使⽤"可选字段"，这时,⾸部长度会有所增加，但最长不超过60字节
源端⼝ - 16bit
来源处的端⼝号；端⼝号有65536个，即$2^{16}$。
⽬的端⼝ - 16bit
⽬的处的端⼝号
无声鼠标序号 - 32bit
TCP在对数据进⾏分段的时候，会给每⼀个TCP报⽂段添加⼀个序号，序号字段的值其实是该⽂段所发送的数据的第⼀个字节的序号。这么做的原因是，TCP是⾯向连接的可靠服务，这个序号可以保证数据在传输过程中保持有序性，接受端可以通过这个序号确认收到的数据的完整性和先后顺序；
确认号 - 32bit
确认号，是期望收到对⽅的下⼀个报⽂段的数据的第⼀个字节的序号；
数据偏移 - 4bit
其实它本质上就是“⾸部长度”，因为“数据偏移”是指TCP报⽂段的数据部分的起始处距离TCP报⽂段的起始处的距离。（仍然很拗⼝，但相信你能明⽩）。
数据偏移总共占4bit，因此最⼤能表⽰的数值为15。但TCP的报⽂头部⾄少为20字节。因此数据偏移的单位是“4字节”，此处的设计和IP数据报的设计是完全相同的，所以说TCP报⽂段⾸部的长度最长为15×4=60字节，且⾸部长度必须为4字节的整数倍。
保留字段 - 6bit
IETF⽂档指出，这6bit在标准中是保留字段，留待以后使⽤，必须为0。我猜测，有两个⽬的，第⼀个是预留除URG/ACK/PSH/RST/SYN/FIN/之外的冗余功能位；第⼆个是为了对齐字节位。
控制位 - 6bit
⼜称为TCP flag，该字段从左到右分为以下六个字段，指明包的类型。同时⽤于控制TCP的状态机，同时ACK和SYN与三次握⼿协议有关，FIN与四次挥⼿协议有关。
① 紧急字段URG - 1bit
当URG=1时，此字段告诉系统此报⽂段中有紧急数据，应尽快传送。
② 确认字段ACK - 1bit
当ACK=1时，表⽰确认，且确认号有效；当ACK=0时，确认号字段⽆效。
③ 推送字段PSH - 1bit
当PSH=1时，则报⽂段会被尽快地交付给⽬的⽅，不会对这样的报⽂段使⽤缓存策略。
④ 复位字段RST - 1bit
当RST为1时，表明TCP连接中出现了严重的差错，必须释放连接，然后再重新建⽴连接。
⑤ 同步字段SYN - 1bit
当SYN=1时，表⽰发起⼀个连接请求。
⑥ 终⽌字段FIN - 1bit
⽤来释放连接。当FIN=1时，表明此报⽂段的发送端的数据已发送完成，并要求释放连接。
窗⼝字段 - 16bit
此字段⽤来控制对⽅发送的数据量，单位为字节。
⼀般TCP连接的其中⼀端会根据⾃⾝的缓存空间⼤⼩来确定⾃⼰的接收窗⼝⼤⼩，然后告知另⼀端以确定另⼀端的发送窗⼝⼤⼩。该字段与TCP的流量控制服务有关。
校验和字段 - 16bit
与IP协议的检验和不同，TCP的这个校验和是针对⾸部和数据两部分的。
紧急指针字段 - 16bit
紧急指针指出在本报⽂段中的紧急数据的最后⼀个字节的序号。
三次握⼿四次挥⼿(这词都听吐了，换个叫法:⼀键三连，取消三连加取关/滑稽))
还有⼀点其实⼈家是Three-way handshake，三步握⼿四步挥⼿的，谁握⼿握三次，挥⼿挥四次的,/吃⽠
TIP：注意箭头的指向，结合⽂字进⾏理解，箭头没有问题
1. ⼀键三连
在三连之前服务器和客户端都为CLOSED状态.通信开始前，双⽅都得创建各⾃的传输控制块(TCB)
服务器创建完TCB后便进⼊LISTEN状态此时准备接受客户端发来的连接请求
点赞(第⼀次握⼿)
客户端向服务端发送连接请求报⽂段.该保温段的头部中SYN=1,ACK=0,seq=X.请求发送后客户端便进⼊SYN-SENT状态
SYN = 1,ACK = 0表⽰该报⽂段位连接请求报⽂
x为本次TCP通信的字节流的初始序号
TIP:TCP规定SYN = 1的报⽂段不能有数据部分，但要消耗⼀个序号
投币(第⼆次握⼿)
服务端收到连接请求报⽂段后，如果同意连接，则会发送⼀个应答:SYN = 1,ACK = 1,seq = y,ack = x + 1
该应答发送完成后便进⼊SYN-RCVD状态.
SYN=1，ACK=1表⽰该报⽂段为连接同意的应答报⽂
seq=y表⽰服务端作为发送者时，发送字节流的初始序号杜仲橡胶种植
ack=x+1表⽰服务端希望下⼀个数据报发送序号从x+1开始的字节
收藏(第三次握⼿)
当客户端收到连接同意的应答后，还要向服务端发送⼀个确认报⽂段，表⽰服务端发来的连接同意应答已经收到
该报⽂头部为:ACK = 1, seq = x + 1, ack = y + 1.
客户端发完这个报⽂后便进⼊ESTABLSHED状态，服务端收到这个应答后也进⼊ESTABLISHED状态，此时连接的建⽴完成
2. 取消三连加取关
TCP连接的释放⼀共需要四部，因为TCP连接时双向的，因此在四次挥⼿中，前两次挥⼿⽤于断开⼀个⽅向的连接，后两次挥⼿⽤于断开另⼀⽅向连接
取消点赞(第⼀次挥⼿)
若客户端认为数据发送完成，则它需要向服务端发送连接释放请求.该请求只有报⽂头，头中携带的主要参数为:
FIN = 1,seq = u此时，客户端将进⼊FIN-WAIT-1状态
FIN = 1表⽰该保温是⼀个连接释放请求
seq = u,u - 1是A向B发送的最后⼀个字节的序号
取消投币(第⼆次挥⼿)
服务端收到连接释放请求后，会通知相应的应⽤程序，告诉它客户端向服务端这个⽅向的连接已经释放.此时服务端进⼊CLOSE-WAIT状态，并向客户端发送连接释放的回答，其报⽂头包含: ACK = 1,seq = v, ack = u + 1气囊减震
ACK=1：除TCP连接请求报⽂段以外，TCP通信过程中所有数据报的ACK都为1，表⽰应答。
seq=v，v-1是B向A发送的最后⼀个字节的序号。
ack=u+1表⽰希望收到从第u+1个字节开始的报⽂段，并且已经成功接收了前u个字节
客户端收到应答进⼊FIN-WAIT-2状态，等待服务端发送连接释放请求
第⼆次挥⼿完成后，客户端到服务端⽅向的连接已经释放，服务端不会接受数据，客户端也不会发送数据，但服务端到客户端的连接仍然存在，服务端可以继续向客户端发送数据
取消收藏(第三次挥⼿)
当服务端发送完所有数据后，向客户端发送连接释放请求，请求头:FIN = 1,ACK, seq = w,ack = u+1.服务端便进⼊LAST-ACK状态.
bbzs取消关注(第四次挥⼿)
当客户端收到释放请求后向B发送确认应答，此时客户端进⼊TiME-WAIT状态，该状态会持续2MSL(2分钟)时间，若该时间没有服务端重发请求的话，就进⼊CLOSED状态，撤销TCB.当服务端收到确认应答后，也进⼊CLOSED状态撤销TCB
