IP报头的理解以及TCP和UDP

这是IPV4的报头
1、VER 代表版本这里为V4 大小为4bite
2、IHL IP包的头部长度 大小为4bite
注意：整个IP头部一般为20字节 最大为60字节 （1111）*32=480bite
3、Service Type：服务类型 8bite 前3个比特（COS）表示优先级，TOS 第4个比特表示要求有更低的时延，第5个比特表示要求有更高的吞吐量，第6个比特表示要求更高的可靠性，第7个比特表示选择价格更低廉的路由，最后一个比特未用。
4、Packet Length：16bite 数据包的总长度包括报头长度和数据长度 最大为65536字节
5、Identification：标示符16bite 用于数据分段，一个数据报在传输过程中可能分成若干段，标识符可以区分某分段属于某报文，一个数据报的所有分段具有相同的标识符。
6、Flag：3bite 它是用来标志数据包是否分段，其中包含DF（do not fragment）和MF(more fragment)，当DF的值为1时，则MF的值必为0，DF为1，则说明数据包有分段。同样可以知道当MF为1时，则DF为0，这表示的是数据包没有分段。当然也有可能MF和DF都为0。
7、Frag offset：段偏移 15bite 用于描述此分段在数据包中的位置
TTL：生存时间 8bite TTL最大为255 经过一个路由器减1，减到0时数据包被丢弃
Protocol：协议8bite这个字段指示IP下一步应当把这个数据包发往更高层的协议，如TCP为6，UDP为17。
8、Header Checksum：头部校验和16bite 计算IP 头部的校验和，检查报文头部的完整性
9、Source Address：源地址 32bite Destinaltion Adderss：目标地址 32bite
10、Options：IP可选项 24bite 用于提供一些数据报可选的服务 时间戳、记录路由等
11、Padding：填充项 Options一般为0或者是32bit的倍数 如果不够32bite或者32bite的倍数则由Padding补齐

UDP：用户数据报文协议—–传输层标配协议—-非面向连接的不可靠传输协议

内容：16位源端口 16位目标端口
16位的UDP包长度 UDP头部和UDP数据的总长度字节
16位头部校验和 此字段是可选项
仅提供端口号—-0-65535 1-1023注明端口 1024-65535动态端口（高端口）
客户端访问服务器时，随机在高端口中分配一个进程号；作为数据包中的源端口—用于区分客户端上的程序进程；使用注明端口来作为目标端口，用于告知所要访问的服务；

TCP：传输控制协议—-在完成了传输的基本工作（分段、端口）外，还可以保障数据包可靠性
面向连接的可靠传输协议

16位源端口 16位目的端口
32位序列编号 用来解决网络包乱序（reordering）问题。
32位确认序号 ACK 用于确认收到数据包，用来解决不丢包的问题。
4位首部长度 表示该tcp报头有多少个4字节(32个bit)
6位的保留位
6位标志位
URG: 标识紧急指针是否有效
ACK: 标识确认序号是否有效
PSH: 用来提示接收端应用程序立刻将数据从tcp缓冲区读走
RST: 要求重新建立连接. 我们把含有RST标识的报文称为复位报文段
SYN: 请求建立连接. 我们把含有SYN标识的报文称为同步报文段
FIN: 通知对端, 本端即将关闭. 我们把含有FIN标识的报文称为结束报文段

16位窗口大小 用来数据传输时的流量控制避免拥塞
16位校验和 发送端填充, 检验形式有CRC校验等. 如果接收端校验不通过, 则认为数据有问题. 此处的校验和不光包含TCP首部, 也包含TCP数据部分
16位紧急指针: 用来标识哪部分数据是紧急数据

TCP的三次握手

第一次握手 客户端向服务端发SYN包请求连接此时SYN=1 随机产生seq=J等待服务器确认
第二次握手 服务端收到SYN=1的包知道客户端请求连接，服务端将SYN和ACK都置为1 ack=J+1来确认客户端的seq，再随机产生一个seq=K发给客户端请求连接
第三次握手 客户端收到服务端的包检查ack是否为J+1 ACK是否为1若是，则发送ack=K+1和ACK=1给服务端，服务端进行检查ack=K+1 ACK=1 若正确则；连接成功

为什么不是二次握手？
二次握手其实并不影响连接的建立，但是如果在请求建立的过程中由于网络的拥塞客户端发往服务端的连接请求迟迟到不了，客户端超时重传。
网络恢复后客户端与服务端建立连接，传输完数据后释放连接。此时被堵塞的连接到了服务端因为没有第三次握手所以服务器认为自己与客户端建立了连接便去等待客户端发送数据，而此时客户端已经关闭了连接，那么服务端就会白白浪费资源

TCP四次断开

第一次断开 A向B发送FIN用来关闭与B之间的TCP会话
第二次断开 B发送ACK用确认自己已经收到了断开的消息，此时A不再向B发送数据
第三次断开 B向A发送FIN请求断开TCP
第四次断开 A回复ACK来确认自己已经收到B的断开请求

为什么是四次断开？
因为TCP是临时的全双工，当B收到A的断开请求时，B给A的数据可能还没有传输完毕所以B需要等待数据传输完后才能发给FIN

                                           香草味可乐
                                           如有错误请指针