三次握手和四次挥手网络各层常见协议与网络封装与解封装

yhxtxdy

已于 2022-04-11 12:42:05 修改

阅读量3k

点赞数

文章标签：网络

于 2022-04-11 12:38:08 首次发布

本文链接：https://blog.csdn.net/m0_66431375/article/details/124091343

版权

一.OSI七层模型

OSI七层模型是国际标准化组织（ISO）制定的一个用于计算机或通信系统间互联的标准体系，一般称为OSI参考模型或七层模型。

但是OSI七层模型分的太详细了，且TCP与IP在网络中的广泛应用，所以TCP/IP参考模型成为互联网的主流参考模型。

二.网络各层常用协议

1.物理层

就是比特流，没啥好说的。

2.数据链路层

数据链路层的常见协议就是：以太网---Ethernet;Point-to-Point Protocal——PPP点到点，帧中继等。

3.网络层

网络层常见协议就是：ip协议，ARP协议，ICMP协议。

4.传输层

传输层协议最主要的就是TCP和UDP协议。

5.会话层

LDAP，DAP,SSL等。

6.表示层

LPP等。

7.应用层

应用层协议：HTTP,FTP.SNMP等。

其实作为网络工程师，我们只需要关注前四层，和应用层就好了。表示层与会话层是程序猿的范畴了。

接下来具体讲一些协议报文先从传输层开始

传输层的主要协议就是两种TCP面向连接的，UDP面向无连接的。简单来说就是TCP是可靠的，UDP是不可靠的

TCP协议就是可靠连接，应用在下载东西，和发送信息上面。

TCP的首部报文格式如下

 0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-------------------------------+-------------------------------+
   |          Source Port          |       Destination Port        |
   +-------------------------------+-------------------------------+
   |                        Sequence Number                        |
   +---------------------------------------------------------------+
   |                    Acknowledgment Number                      |
   +-------+-----------+-+-+-+-+-+-+-------------------------------+
   |  Data |           |U|A|P|R|S|F|                               |
   | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
   |       |           |G|K|H|T|N|N|                               |
   +-------+-----------+-+-+-+-+-+-+-------------------------------+
   |           Checksum            |         Urgent Pointer        |
   +-------------------------------+---------------+---------------+
   |                    Options                    |    Padding    |
   +-----------------------------------------------+---------------+
   |                             data                              |
   +---------------------------------------------------------------+

Source Port	16比特	源端口，标识哪个应用程序发送。
Destination Port	16比特	目的端口，标识哪个应用程序接收。
Sequence Number	32比特	序号字段。TCP链接中传输的数据流中每个字节都编上一个序号。序号字段的值指的是本报文段所发送的数据的第一个字节的序号。
Acknowledgment Number	32比特	确认号，是期望收到对方的下一个报文段的数据的第1个字节的序号，即上次已成功接收到的数据字节序号加1。只有ACK标识为1，此字段有效。
Data Offset	4比特	数据偏移，即首部长度，指出TCP报文段的数据起始处距离TCP报文段的起始处有多远，以32比特（4字节）为计算单位。最多有60字节的首部，若无选项字段，正常为20字节。
Reserved	6比特	保留，必须填0。
URG	1比特	紧急指针有效标识。它告诉系统此报文段中有紧急数据，应尽快传送（相当于高优先级的数据）。
ACK	1比特	确认序号有效标识。只有当ACK=1时确认号字段才有效。当ACK=0时，确认号无效。
PSH	1比特	标识接收方应该尽快将这个报文段交给应用层。接收到PSH = 1的TCP报文段，应尽快的交付接收应用进程，而不再等待整个缓存都填满了后再向上交付。
RST	1比特	重建连接标识。当RST=1时，表明TCP连接中出现严重错误（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立连接。
SYN	1比特	同步序号标识，用来发起一个连接。SYN=1表示这是一个连接请求或连接接受请求。
FIN	1比特	发端完成发送任务标识。用来释放一个连接。FIN=1表明此报文段的发送端的数据已经发送完毕，并要求释放连接。
Window	16比特	窗口：TCP的流量控制，窗口起始于确认序号字段指明的值，这个值是接收端期望接收的字节数。窗口最大为65535字节。
Checksum	16比特	校验字段，包括TCP首部和TCP数据，是一个强制性的字段，一定是由发端计算和存储，并由收端进行验证。在计算检验和时，要在TCP报文段的前面加上12字节的伪首部。
Urgent Pointer	16比特	紧急指针，只有当URG标志置1时紧急指针才有效。TCP的紧急方式是发送端向另一端发送紧急数据的一种方式。紧急指针指出在本报文段中紧急数据共有多少个字节（紧急数据放在本报文段数据的最前面）。
Options	可变	选项字段。TCP协议最初只规定了一种选项，即最长报文段长度（只包含数据字段，不包括TCP首部），又称为MSS。MSS告诉对方TCP“我的缓存所能接收的报文段的数据字段的最大长度是MSS个字节”。新的RFC规定有以下几种选型：选项表结束，空操作，最大报文段长度，窗口扩大因子，时间戳。选项表结束。空操作：没有特殊含义，一般用于将TCP选项的总长度填充为4字节的整数倍。最大报文段长度：又称为MSS，只包含数据字段，不包括TCP首部。窗口扩大因子：3字节，其中一个字节表示偏移值S。新的窗口值等于TCP首部中的窗口位数增大到（16+S），相当于把窗口值向左移动S位后获得实际的窗口大小。时间戳：10字节，其中最主要的字段是时间戳值（4字节）和时间戳回送应答字段（4字节）。
Padding	可变	填充字段，用来补位，使整个首部长度是4字节的整数倍。
data	可变	TCP负载。

TCP里面最重要的就是三次握手，与四次挥手。

三次握手建立连接

当PC1想与PC2通信需要建立连接。

PC1向PC2发送请求连接的SYN同步信号，其中序列号为a，确认号为0

PC2收到PC1发来的SYN同步请求，ACK确认号：PC2确认收到PC1的信息，将PC1发来的Seq，序列号加一，ack=a+1。注意不是什么情况下确认号都加一，要发来的报文中要有SYN，或者FIN信息才加一如果有长度ACK确认号也需要加上长度,PC2确认收到了PC1的报文还没有结束，PC2也需要和PC1建立连接，PC2向PC1发送SYN的请求序列号为b，seq=b

PC1收到了PC2的确认信息序列号就为PC2发来的确认号Seq=a+1,同时PC1也收到了PC2发来的请求同步的信息，也需要回复给PC2一个确认信息，PC1收到的PC2的序列号为b，要回复一个ACK确认号=b+1。

TCP三次握手就相当与，你和你暗恋的人表白，你发送信息给她说我喜欢你（发送一个SYN），如果你的暗恋的人只回复一个好的（相当与确认号ACK），你怎么知道是什么意思是好的我同意，还是说好的但是你是个好人我不同意，所以需要你的暗恋对象发送好的，我也喜欢你（确认前面你的信息然后发送一个自己的请求）。当你收到这个信息之后你也需要回复一个ACK的请求，不然你的暗恋对象怎么知道你收没收到刚刚她的信息。所以说TCP是一个可靠的传输协议，当接受主机发现序列号漏了之后，会向发送主机在请求一遍漏掉的序列号。

TCP四次挥手

当数据传输完毕之后，PC1需要给PC2发送一个FIN请求断开的连接，seq序列号=101，ACK确认号=301。

当PC2收到PC1的请求断开的连接之后PC2回复一个ACK确认号，序列号=PC1的ACK,确认PC1发来的FIN里面信息，ACK号=PC1的序列号加1要是有头部长度也需要加上，但是这时候不能断开，因为PC1发完了但是PC2还有可能没有收完。

所以当PC2也接收完毕之后也给PC1发送一个FIN的请求，请求断开连接序列号=301,确认号为=PC1的序列号加一。

当PC1收到PC2的确认和请求断开信息之后，PC1也需要给PC2回复一个确认信息，确认我已经收到，序列号为302的信息。

TCP四次挥手就相当与：你和你女朋友说分手（FIN），你的女朋友回复好的（ACK）但是你的东西要给我我全收到之后，给你也回一个我们分手（FIN），这时候你收到这个信息之后你也需要会一个确认信息好的（ACK）我同意。TCP也有弊端。因为是可靠连接所以当接受端查到序列号发现丢包的时候，会在向发送端再次请求该信息，当你在打游戏的时候就会因为前面网络不好然后导致丢包之后再去请求前面的信息，你的游戏就没法玩了，网络一丢包就去请求前面的信息，那不是纯纯坑队友嘛，所以此时就出现了UDP传输协议，不可靠的协议。

可以抓一个TCP三次握手和四次挥手的包看看如图

三次握手

四次挥手

UDP协议就只管发，不管对端能不能收到，应用在视频聊天和游戏中。

UDP报文格式

 0              15 16             31
       +-----------------+-----------------+
       | Source Port     |Destination Port |
       +-----------------+-----------------+
       |                 |                 |
       |     Length      |    Checksum     |
       +-----------------+-----------------+
       |                                   |
       |          data octets ...          |
       +-----------------------------------+

Source Port	2字节	标识哪个应用程序发送（发送进程）。
Destination Port	2字节	标识哪个应用程序接收（接收进程）。
Length	2字节	UDP首部加上UDP数据的字节数，最小为8。
Checksum	2字节	覆盖UDP首部和UDP数据，是可选的。
data octets	变长	UDP负载，可选的。

UDP很简单没有啥确认号啥乱七八糟的东西，我只需要知道源端口与目的端口。就可以发不管对端有没有收到。

网络层协议主要的就是IP和ICMP,ARP。

IP格式

0       3       7              15              23              31
+---------------------------------------------------------------+
|Version|  IHL  |Type of Service|           Total Length        |
+---------------------------------------------------------------+
| Identification                | Flags |      Fragment Offset  |
+---------------------------------------------------------------+
| Time to Live  |   Protocol    |        Header Checksum        |
+---------------------------------------------------------------+
|                           Source Address                      |
+---------------------------------------------------------------+
|                           Destination Address                 |
+---------------------------------------------------------------+
|                   Options                     |    Options    |
+---------------------------------------------------------------+

Version	设置为4。
IHL	指外层IP头部长度，以32比特为计算单位。
Type of Service	从内层IP头部复制。
Total Length	指整个IP负载的长度，包括外层IP头，内层IP头和IP负载。
Identification, Flags, Fragment Offset	这三个字段的含义与RFC791的定义相同。注意，如果内层IP头部的DF位置位，外层IP头部的DF位也必须置位。如果内层IP头的DF未置位，外层IP头部的DF位可以置位也可以不置位。
Time to Live	外层IP头部的TTL域设置为发送该数据包到隧道目的端的合适的值。
Protocol	设置为4。
Header Checksum	外层IP头部的校验字段。
Source Address	执行该IPinIP隧道头封装的隧道入口设备的IP地址。
Destination Address	执行该IPinIP隧道头解封装的隧道出口设备的IP地址。
Options	内层IP头部的任何选项字段通常不被复制到外层IP头部。隧道路径上的设备可以添加新的选项字字段。内层IP头部的安全选项字段的类型可能影响外层IP头部的安全选项字段的选择。

ICMP，主要用的就是ping与tracert，报文格式如下

+0------7-------15---------------31
|  Type | Code  |    Checksum    |
+--------------------------------+
|          Message Body          |
|        (Variable length)       |
+--------------------------------+

Type	1字节	报文类型，用来标识报文，Type字段的取值和含义如表1所示。
Code	1字节	代码，提供报文类型的进一步信息，Code字段的取值和含义如表1所示。
Checksum	2字节	校验和，使用和IP相同的加法校验和算法，但是ICMP校验和仅覆盖ICMP报文。
Message Body	可变	字段的长度和内容，取决于消息的类型和代码，请参见表1。