目录
参考：TCP//IP协议
章节目标
- 了解互联网是怎么通信的？
- 掌握TCP/IP协议栈
4.1 概述
1.为什么会有TCP/IP协议
- 在世界上各地，各种各样的电脑运行着各自不同的操作系统为大家服务，这些电脑在表达同一种信息的时候所使用的方法是千差万别。就好像圣经中上帝打乱了各地人的口音，让他们无法合作一样。计算机使用者意识到，计算机只是单兵作战并不会发挥太大的作用。只有把它们联合起来，电脑才会发挥出它最大的潜力。于是人们就想方设法的用电线把电脑连接到了一起。
- 但是简单的连到一起是远远不够的，就好像语言不同的两个人互相见了面，完全不能交流信息。因而他们需要定义一些共通的东西来进行交流，TCP/IP就是为此而生。
2.介绍
- ①1960年代，美国国防部组建的军事网络-阿帕网（APRANET ），而TCP/IP协议栈则是运行在阿帕网上的通信协议族；
- ②需要接入阿帕网联网的设备，都需要安装TCP/IP协议栈（可以看出一个软件或者驱动）；
- ③同时代的通信协议栈还有很多，例如IBM公司开发的SNA网络体系结构，DEC公司开发的DNA网络体系结构 ；不同公司和政府之间网络不同兼容；
- ④1983年，国际标准化委员会（ISO）发布了 OSI标准（开发系统互联模型），采用七层模型来统一不同的网络标准；
- ⑤随着网络的发展，以美国军方为代表的 TCP/IP通信机制凭借前期优势最终在市场上战胜其他企业标准；现在的电脑都是安装TCP/IP协议栈进行通信。
- ⑥**TCP/IP不是一个协议，而是一个协议族的统称。**里面包括了IP协议，IMCP协议，TCP协议，以及我们更加熟悉的http、ftp、pop3协议等等。电脑有了这些，就好像学会了外语一样，就可以和其他的计算机终端做自由的交流了。
- ⑦从字面意义上讲，有人可能会认为 TCP/IP 是指 TCP 和 IP 两种协议。实际生活当中有时也确实就是指这两种协议。然而在很多情况下，它只是利用 IP 进行通信时所必须用到的协议群的统称。具体来说，IP 或 ICMP、TCP 或 UDP、TELNET 或 FTP、以及 HTTP 等都属于 TCP/IP 协议。
4.2 TCP/IP协议族
4.2.1 TCP/IP协议栈
1.协议的分层
- 网络协议通常分不同层次进行开发，每一层分别负责不同的通信功能。一个协议族，比如TCP/IP，是一组不同层次上的多个协议的组合。 传统上来说 TCP/IP 被认为是一个四层协议, 而ISO（国际标准化组织），制定了一个国际标准OSI七层协议模型，OSI协议以OSI参考模型为基础界定了每个阶层的协议和每个阶层之间接口相关的标准。
- tcp/ip 四层模型，从上到下依次是应用层，传输层，网络层，网络接口层（数据链路层）
2. 主机与主机之间通信的三要素
- IP地址（IP address）
- 子网掩码（subnet mask）
- IP路由（IP router）
3.应用层
- 向用户提供一组常用的应用程序，比如**电子邮件、文件传输访问、远程登录等。**远程登录TELNET使用TELNET协议提供在网络其它主机上注册的接口。TELNET会话提供了基于字符的虚拟终端。文件传输访问FTP使用FTP协议来提供网络内机器间的文件拷贝功能。
- 作用：为用户提供软件/接口。
- 软件：
- 即时通讯=> 微信、QQ、陌陌、脉脉、钉钉
- 购物软件=>天猫、京东、美丽说、唯品会
- 影音类=>暴风影音、风行、PPS、爱奇艺
4.传输层
- 作用：用于实现数据的可靠或不可靠传输。
- 提供应用程序间的通信。其功能包括：
- 一、格式化信息流；
- 二、提供可靠传输。为实现后者，传输层协议规定接收端必须发回确认，并且假如分组丢失，必须重新发送。
- 协议：TCP、UDP
- TCP(Transimision Control Protocal) ：传输控制协议
1. 可靠的、面向连接的协议
1. 传输效率低 - UDP(User Datagram Protocal)：用户数据报协议
1. 不可靠的、无连接的服务
1. 传输效率高
- TCP(Transimision Control Protocal) ：传输控制协议
5.网络层
- 作用：提供IP地址和三层通信（路由器）功能。
- 负责相邻计算机之间的通信。其功能包括三方面。
- 一、处理来自传输层的分组发送请求，收到请求后，将分组装入IP数据报，填充报头，选择去往信宿机的路径，然后将数据报发往适当的网络接口。
- 二、处理输入数据报：首先检查其合法性，然后进行寻径–假如该数据报已到达信宿机，则去掉报头，将剩下部分交给适当的传输协议；假如该数据报尚未到达信宿，则转发该数据报。
- 三、处理路径、流控、拥塞等问题。
- 协议：IP协议。
6.网络接口层
- 作用：提供MAC地址和二层通信（交换机）功能。
- 这是TCP/IP软件的最低层，负责接收IP数据报并通过网络发送之，或者从网络上接收物理帧，抽出IP数据报，交给IP层。
- 协议：Ethernet协议
4.2.2 数据封装与解封装（发送接收过程）
- ①数据封装是一个为数据包加入寻址信息的过程（类似快递）。
- ②端口号用于标志不同的应用程序，面向最终用户（80代表http/浏览器，8000代表oicq/qq） 。
- ③IP地址用于唯一标志通信设备，面向路由器 。
- ④MAC地址用于唯一标志局域网设备，面向交换机 。
4.2.3 IP
1.概述
- IP 用于计算机之间的通信。
- IP 是无连接的通信协议。它不会占用两个正在通信的计算机之间的通信线路。这样，IP 就降低了对网络线路的需求。每条线可以同时满足许多不同的计算机之间的通信需要。
- 通过 IP，消息（或者其他数据）被分割为小的独立的包，并通过因特网在计算机之间传送。
- IP 负责将每个包路由至它的目的地。
- IP是可以被追踪到和定位的，无论是网上发帖造谣生事或通过黑客技术攻击别人，所做的事情都会基于IP和其他ID信息被服务器记录下来，然后"阿sir"就可以追踪并抓到你。
2.IP地址
- 用来标识一个网络节点的互联网地址。
- 每个计算机必须有一个 IP 地址才能够连入因特网。
- 每个 IP 包必须有一个地址才能够发送到另一台计算机。
- 网络上每一个节点都必须有一个独立的Internet地址（也叫做IP地址）。
3.IP地址组成（点分十进制）【IPv4】
- 一共32个二进制位
- 转换为4个十进制数表示，以点隔开
- 通常采用 x. x. x. x的格式，每个x为8位。
- IP地址的组成
- IP地址是由两部分组成的，网络部分（网络位）和主机部分（主机位），比如：
4.IP地址分类
- IP地址类型分为A、B、C、D、E
1. A类，1~127.主.主.主 (1.0.0.0–126.255.255.255) ==> 子网掩码 255.0.0.0 或 /8
2. B类，128~191.网.主.主(128.0.0.0–191.255.255.255) ==> 子网掩码 255.255.0.0 或 /16
3. C类，192~233.网.网.主(192.0.0.0–233.255.255.255) ==> 子网掩码 255.255.255.0 或 /24
4. E类，240~254科研
5. 组播及科研- D类，244~239组播
- 预留组播地址
| 路由协议使用
| 244.0.0.0~244.0.0.255 - 公用组播地址
| Internet使用
| 244.0.1.0~244.0.1.255 - 用户组播地址
| 用户临时使用
| 244.0.2.0.255~238.255.255.255 - 本地管理组播地址
| 本地管理组播地址，特定本地范围
| 239.0.0.0~239.255.255.255
- 预留组播地址
- D类，244~239组播
- 子网掩码：用于区分IP地址的网络位和主机位
- 默认情况下：网络位用255表示，主机位用0表示
- IP地址分类续【根据使用范围区分】
- 公有地址：可以在互联网合法使用，需要向NIC付费申请
- 私有地址：预留给企业内部使用，无需付费
- 回环地址：本机TCP/IP回环测试 （127.0.0.1~127.255.255.254）
类别 私有地址 A类 10.0.0.1~10.255.255.254 B类 172.16.0.1~172.31.255.254 C类 192.168.0.1~192.168.255.254
- IP地址中的特殊地址
5.默认网关
- 什么是网关
- 从一个网络连接另一个网络的“关口”
- 通常是一台路由器，或者是防火墙/接入服务器的地址
6.域名
- IP地址（12 个阿拉伯数字）很难记忆。使用一个名称更容易。
- 用于 TCP/IP 地址的名字被称为域名。www.baidu.com就是一个域名。
- 当你键入一个像https://www.baidu.com/这样的域名，域名会被一种 DNS 程序翻译为IP地址。
- 在全世界，数量庞大的 DNS 服务器被连入因特网。DNS 服务器负责将域名翻译为 TCP/IP 地址，同时负责使用新的域名信息更新彼此的系统。
- 当一个新的域名连同其 TCP/IP 地址一同注册后，全世界的 DNS 服务器都会对此信息进行更新。
4.2.4 Ethernet协议 【网络接口层 以太网协议】
1 概述
- Ethernet 以太网协议，用于实现链路层（网络接口层）的数据传输和地址封装。
- 目前主要有两种格式的以太网帧：Ethernet II（DIX 2.0）和IEEE 802.3。
- IP、ARP、EAP和QICQ协议使用Ethernet II帧结构，而STP协议则使用IEEE** 802.3帧**结构。
- Ethernet II是由Xerox与DEC、Intel（DIX）在1982年制定的以太网标准帧格式，后来被定义在RFC894中。
- IEEE 802.3是IEEE 802委员会在1985年公布的以太网标准封装结构（可以看出二者时间相差不多，竞争激烈），RFC1042规定了该标准（但终究二者都写进了IAB管理的RFC文档中）。
1-半 MAC地址（网卡）
-
①所有设备的MAC地址都是全球唯一的；
-
②MAC全称Medium Access Control，直译为介质访问控制，它通常被固化在每个以太网网卡（NIC,Network Interface Card）。MAC（硬件）地址长48位（6字节），采用十六进制格式。
-
③MAC地址前半部分被称为**“OUI代码”**厂商唯一标志符，用于唯一标志一个企业/公司，例如思科、TP-LINK、华为；后半部分厂商自行分配。
-
下图说明了48位的MAC地址及其组成部分。
-
-
示例： 00-01-6C-06-A6-29 或 00:01:6C:06:A6:29
- 组织唯一标识符（OUI）由IEEE（电气和电子工程师协会）分配给厂商，它包含24位。厂商再用剩下的24位（EUI，扩展唯一标识符）为其生产的每个网卡分配一个全球唯一的全局管理地址，一般来说大厂商都会购买多个OUI。
- I/G（Individual/Group）位，如果I/G=0，则是某台设备的MAC地址，即单播地址；如果I/G=1，则是多播地址（组播+广播=多播）。
- G/L（Global/Local，也称为U/L位，其中U表示Universal）位，如果G/L=0，则是全局管理地址，由IEEE分配；如果G/L=1，则是本地管理地址，是网络管理员为了加强自己对网络管理而指定的地址。
- 详细内容浏览该链接
2 Ethernet II 的帧格式
- 协议结构
前导码 目的mac地址（DMac） 源mac地址 (SMac) 类型(Type) 数据(Data) 校验（FCS） 8 Byte 0 1间隔 6 Byte 目的地址 6 Byte 源地址 2 Byte 46 ~ 1500 Byte 4 Byte CRC检验
- 解释
- 前导码： 占8个字节，0 1 相间隔组成。其作用是用于给基站识别即将到来的数据。
- 目的mac地址： 接收设备的mac地址。
- 源mac地址：发送设备的mac地址。
- 类型： 占2个字节，用于标记数据（Data）的协议类型。
-
类型（Type） Data中的协议类型 0x0800 IPv4（Internet Protocol Version 4） 0x0806 ARP （Address Resulotion Protocol） 0x0835 RARP (Resever Address Resulotion Protocol) 0x86DD IPv6 (Internet Protocol Version 6)
-
- 数据： 46-1500个字节。
- 校验： 循环冗余校验字段，4个字节，用于核对数据是否接收正确。
- Wireshark接收到的数据包均为网卡校验正确的数据包，所以没有了前导码与校验(FCS)数据。
3 IEEE 802.3 的帧格式
- 协议结构
- 解释
- 帧初始同步 ：7字节长，每字节由10101010组成，使接收端同步。
- 开始分隔符 ： 1字节长 由10101011组成，指示帧开始。
- 目的地址 ：和Ethernet II 基本相同，不同的是该地址还支持2字节的地址。
- 源地址 ：和Ethernet II 基本相同，不同的是该地址还支持2字节的地址。
- 长度 ：2字节长，指示从LLC头开始字节到有效载荷的最后一个字节的字节数，不包括IEEE 802.3的头和FCS字段 ，最小是46 (0x002E)最大是1500(0x05DC)。
- DSAP ：目的服务访问点（DestinationService Access Point,DSAP）字段，1字节长，指明帧的目的上层协议类型。
- SSAP ：源服务访问点（SourceService Access Point,SSAP）字段，1字节长，指明帧的源上层协议类型。
- 控制 ：1字节或者2字节，确定的长度要看被封装的LLC数据类型，是LLC数据报(类型1)1字节，LLC对话的一部分(类型2)2字节。
- 类型1 ：_表明是无连接的，不可靠的LLC数据报，控制字段用0x03指明。
- 类型2 ：表明是面向连接可靠的LLC会话。
- 虽然IEEE 802.3是标准，但没有被业界采用。以太网II已成事实标准。于是IEEE 802.3扩展产生 IEEE 802.3 SNAP 来兼容以太网网头部协议，在IEEE 802.2 LLC 头部后插入了SNAP头部。（SNAP头部 如上图所示）
- 为了标识SNAP帧，DSAP和SSAP在LLC头都被设置成SNAP定义的值0xAA，所有SNAP的封装没有使用可靠的LLC服务，所以控制设置成0x03。
- 组织代码 ：3字节长，指明维护接下来2字节意义的组织，对IP和 ARP，该字段被设置为0x00-00-00。
- 类型 ：占2个字节，以太网类型。
- 帧校验序列(FCS) 4字节 和Ethernet II 一样。
- 总结
- 如何区分IEEE 802.3的帧和Ethernet II 的帧？
- 两种格式的帧源地址后字段含义不同，IEEE 802.3 是长度，长度范围是在区间[46,1500],十六进制[0x002E,0x05DC],以太网II是以太网类型，值最小位0x0600XNS（Xerox的网络系统）协议，大于1500.
- Ethernet V2比IEEE802.3更适合于传输大量的数据，但Ethernet V2缺乏数据链路层的控制，不利于传输需要严格传输控制的数据，这也正是IEEE802.3的优势所在，越需要严格传输控制的应用，越需要用 IEEE802.3或SNAP来封装，但IEEE802.3也不可避免的带来数据装载量的损失，因此该格式的封装往往用在较少数据量承载但又需要严格控制传输的应用中。
- 在实际应用中，我们会发现，大多数应用的以太网数据包是Ethernet V2的帧（如HTTP、FTP、SMTP、POP3等应用），而交换机之间的BPDU（桥协议数据单元）数据包则是IEEE802.3的帧，VLAN Trunk协议如802.1Q和Cisco的CDP（思科发现协议）等则是采用IEEE802.3 SNAP的帧。
- 如何区分IEEE 802.3的帧和Ethernet II 的帧？
- LLC（Logical Link Control）逻辑链路控制，由目的服务访问点DSAP（Destination Service Access Point）、源服务访问点SSAP（Source Service Access Point)和Control字段组成；
- SNAP（Sub-network Access Protocol）由机构代码（Org Code）和类型Type字段组成。Org Code三个字节都为0。Type字段的含义与Ethernet II中Type字段相同；
- IEEE802.3帧根据DSAP和SSAP字段的取值，又可以分为以下几类：
- 当DSAP和SSAP都取特定值0xff时，802.3帧就变成了Netware-ETHERNET帧，用来承载NetWare类型的数据；
- 当DSAP和SSAP都取特定值0xaa时，802.3帧就变成了ETHERNET_SNAP帧。此帧可以用于传输多种协议。
- DSAP和SSAP其他的取值均为纯IEEE802.3帧
4.2.5 网络层协议
1 IP协议 （I want to send data to 192.168.0.127）【IP网际协议】
- 基本概念
- IP协议（Internet Protocol，互联网协议），是TCP/IP协议栈中最核心的协议之一，通过IP地址，保证了联网设备的唯一性，它提供无连接的不可靠的连接。所有的 TCP、UDP、ICMP及IGMP数据都以I P数据报格式传输。本文IP指IPv4。
- 以PC1访问服务器为例，PC1的地址是12.1.8.66，Server的地址是8.8.4.4，整个通信过程是这样的：
- ①PC1在请求数据包里面封装源目IP地址，并将带有IP地址的数据包发送到互联网；
- ②互联网有大量的网络通信设备（例如路由器），路由器根据数据包的IP地址查找路由表（地图），然后以接力棒的方式逐跳转发直到目标服务器；
- ③服务器收到请求数据后，将源目IP地址翻转，并封装回应数据包发送到互联网。
- 【IP协议字段解读】【IP头部】
- 每个IP数据报包含两部分，一个头和一个正文，正文部分也称之为有效净荷。
- IP协议头是一个20字节的定长部分和一个可选的变长部分。
- Version（版本号）：标识IP协议的版本，目前V4版本地址已经枯竭，V6慢慢成为主流。
- 一般的值为0100（IPv4），0110（IPv6）
- Header Length（头部长度）：默认为20字节，1个IP包头的长度最长60个字节，IP包头最小长度为20字节。
- Type Of Service（服务类型(Tos)）：或者称呼它的新名字—区别服务字节(differrntiated service byte)(DS 字节)，用于为不同的IP数据包定义不同的服务质量，一般应用在QoS技术中，这个字段用来存储反映分组Qos需求的参数。8位 按位被如下定义 PPP DTRC0。
- 在Tos中，这个字段被分为两个子字段 PPP和DTRC0。
- PPP：优先级（3位）和数据链路层的QoS机制有关，定义了8个服务级别。当Qos选择了某种服务模型后，优先级越高，字段越优先传输。
- 000 普通 (Routine)
- 001 优先的 (Priority)
- 010 立即的发送 (Immediate)
- 011 闪电式的 (Flash)
- 100 比闪电还闪电式的 (Flash Override)
- 101 CRI/TIC/ECP(找不到这个词的翻译)
- 110 网间控制 (Internetwork Control)
- 111 网络控制 (Network Control)
- DTRC0
- D 时延: 0:普通 1:延迟尽量小
- T 吞吐量: 0:普通 1:流量尽量大
- R 可靠性: 0:普通 1:可靠性尽量大
- 最后一位被保留，恒定为0
- Total Length （总长度）：标识IP头部加上上层数据的数据包大小，IP包总长度最大为65535个字节。
- Identification （标识符）：用来实现IP分片的重组，标识分片属于哪个进程，不同进程通过不同ID区分。
- 该字段和Flags和Fragment Offest字段联合使用，对较大的上层数据包进行分段（fragment）操作。路由器将一个包拆分后，所有拆分开的小包被标记相同的值，以便目的端设备能够区分哪个包属于被拆分开的包的一部分。
- Flags（标志符）：用来确认是否还有IP分片或是否能执行分片。该字段第一位不使用。第二位是DF（Don’t Fragment）位，第三位是MF（More Fragments）位。
- DF位，DF位设为1时表明路由器不能对该上层数据包分段。如果一个上层数据包无法在不分段的情况下进行转发，则路由器会丢弃该上层数据包并返回一个错误信息。
- MF位，路由器对一个上层数据包分段，则路由器会在除了最后一个分段的IP包的包头中将MF位设为1。
- Fragment offset （分片偏移量）：用于标识IP分片的位置，实现IP分片的重组。
- 表示该IP包在该组分片包中位置，接收端靠此来组装还原IP包。
- Time to live （生存时间）：标识IP数据包还能生存多久，根据操作系统不同，TTL默认值不同，每经过一个三层设备如路由器的处理，则TTL减去1，当TTL=0时，则此数据包被丢弃。
- 当IP包进行传送时，先会对该字段赋予某个特定的值。当IP包经过每一个沿途的路由器的时候，每个沿途的路由器会将IP包的TTL值减少1。如果TTL减少为0，则该IP包会被丢弃。这个字段可以防止由于路由环路而导致IP包在网络中不停被转发。
- Protocol （协议号）：标识IP协议上层应用。当上层协议为ICMP时，协议号为1，TCP协议号为6，UDP的协议号为17。
- 比较常用的协议号：
- 1 ICMP
- 2 IGMP
- 6 TCP
- 17 UDP
- 88 IGRP
- 89 OSPF
- 比较常用的协议号：
- Header checksum （头部校验）：用于检验IP数据包是否完整或被修改，若校验失败则丢弃数据包。
- 用来做IP头部的正确性检测，但不包含数据部分。 因为每个路由器要改变TTL的值,所以路由器会为每个通过的数据包重新计算这个值。
- Source（源IP地址）：标识发送者IP地址，占用32bit。
- Destination （目的IP地址）：标识接收者IP地址，占用32bit。
- Options （可选项）：该字段属于可选项，主要用于测试，由起源设备根据需要改写。可选项目包含以下内容：
- 严格源路由（Strict source routing）：给出一连串路由器接口的IP地址。IP包必须沿着这些IP地址传送，如果下一跳不在IP地址表中则表示发生错误。
- 路由记录（Record route）：当IP包离开每个路由器的时候记录路由器的出站接口的IP地址。
- 时间戳（Timestamps）：当IP包离开每个路由器的时候记录时间。
- 填充（Padding）：因为IP包头长度（Header Length）部分的单位为32bit，所以IP包头的长度必须为32bit的整数倍。因此，在可选项后面，IP协议会填充若干个0，以达到32bit的整数倍。
- 总结：我们可以看到IP头部默认有12个字段（后续会提到特殊字段），为了方便记忆，可以总结为7个核心知识点。
- Source和Destination即IP源目地址字段，是IP协议最核心的字段；
- Id+Flags+FO三个字段可以实现IP数据分片和重组；
- Total Length和Header Length标记IP头部和上层数据的边界；
- TTL生存时间字段可以实现通信防环；
- DSCP服务区分符可以实现流量控制；
- Checksum字段可以数据包完整性校验；
- Protocol字段标记上层应用；
2 ARP协议 （who knows 192.168.0.127’s MAC address?）
- 基本概念
- ARP(Address Resolution Protocol) 即地址解析协议，用于实现从IP地址到MAC地址映射。
- ARP工作流程
- 同一网段ARP工作流程分析
- PC1 要和PC3 通行，首先查看自己的ARP表，查看其中是否包含PC3的MAC地址信息，如果找到对应关系，直接利用ARP表中的MAC地址对IP数据包进行封装。并将数据包发送给PC3。
- 如果PC1在ARP表中未找到PC3对应的MAC地址，则先缓存数据报文，然后利用广播方式（目标MAC地址FF:FF:FF:FF:FF:FF)发送一个ARP报文请求，ARP请求中的发送端MAC地址分别是PC1的IP地址和MAC地址，接收端的IP地址为PC3的IP地址，MAC地址全为0，因为ARP请求报文是以广播方式发送，所以该网段上的所有主机都可以接收到该请求包，但只有其IP地址与目的IP地址一致的PC3才会对该请求进行处理。
- PC3将ARP请求报文中的发送端（即PC1）的IP地址和MAC地址存入自己的ARP表中。然后以单播方式向PC1发送一个ARP相应报文，应答报文中就包含了自己的MAC地址，也就是原来在请求报文中要请求的目的MAC地址。
- PC1收到来自PC3的ARP响应报文之后，将PC3的MAC地址加入到自己的ARP表中以用于后续报文的转发，同时将原来缓存的IP数据包再次修改（在目的MAC地址字段填上PC3的MAC地址）后发送出去。
- 跨网段的ARP地址解析流程
- 如果主机A不知道网关的MAC地址（也就是主机A的ARP表中没有网关对应的MAC地址表项），则主机A先在本网段中发出一个ARP请求广播，ARP请求报文中的目的IP地址为网关的IP地址,代表其目的就是想获得网关的MAC地址。如果主机A已经知道网关的MAC地址，则略过此步。
- 网关收到ARP广播包后同样会向主机A发回一个ARP应答包。当主机A收到的应答包中获得网关的MAC地址后，在主机A向主机B发送的原报文的目的MAC地址字段填上网关的MAC地址后发给网关。
- 如果网关的ARP表中已有主机B对应的MAC地址，则网关直接将在来自主机A的报文中的目的MAC地址字段填上主机B的MAC地址后转发给B。
- 如果网关ARP表中没有主机B的MAC地址，网关会再次向主机B所在的网段发送ARP广播请求，此时目的IP地址为主机B的IP地址，当网关从收到来自主机B的应答报文中获得主机B的MAC地址后，就可以将主机A发来的报文重新再目的MAC地址字段填上主机B的MAC地址后发送给主机B。
- 同一网段ARP工作流程分析
- 注意：ARP 只用于 IPv4 协议中，IPv6 协议使用的是 Neighbor Discovery Protocol，译为邻居发现协议，它被纳入 ICMPv6 中。
- ARP报文格式
-
前面 14 个字节构成标准以太网的首部，前两个字段 DST 和 SRC 分别表示 以太网的目的地址 和 以太网的源地址，以太网的目的地址如果是 ff:ff:ff:ff:ff:ff 全部为 1 表示广播地址，在同一广播域中的所有以太网接口可以接收这些帧。后面紧跟着的是 ARP 请求的长度/类型，ARP 请求 和 ARP 应答这个值为 0x0806。
-
硬件类型：表示硬件地址的类型，硬件地址常见的有 MAC 物理或者以太网地址，对于以太网来说，此值为 1。
-
类型 含义 类型 含义 0x001 以太网 0x0012 本地网 0x002 实验性以太网 0x0013 超链路 0x003 业务无线电 AX.25 0x0014 SMDS 0x004 Proteon ProNet令牌环 0x0015 帧中继 0x005 ChaosNET 0x0016 ATM 0x006 IEEE 802网 0x0017 HDLC(高级数据链路控制) 0x007 ARCnet 0x0018 未指定 0x008 超信道 0x0019 异步传输模式 0x0010 Autone短地址 0x0021 异步传输模式 0x0011 Local talks
-
-
协议类型：指明了发送方提供的高层协议类型，对于 IPv4 地址，这个值是 0x0800。ARP可用于任何高层协议。
-
硬件长度：用来定义物理地址的长度，以字节为单位。例如：对于以太网的值为6。
-
协议长度：高层协议地址的长度，以字节为单位。例如：对于IPv4协议的值为4。
-
操作码：用来定义报文的类型。已定义的分组类型有两种：ARP请求OP=1，ARP响应OP=2。
-
发送方硬件地址(MAC 地址)
-
发送方的协议地址(IPv4 地址)
-
目的硬件地址：对于ARP请求报文，这个字段为全0，因为发送方并不知道目标的硬件地址。
-
目的协议地址
-
报文中的padding字段是填充数据，为了保证帧最少有64个字节。
-
参考
3 RARP协议 （who knows 21.21.12.21.21.12’s IP address?）
- 基本介绍
- RARP（Reverse Address Resolution Protocol）逆地址解析协议
- 就是和ARP协议做相反的工作，它是将48位的MAC地址转换为32位的IP地址
- RARP协议的工作原理
- 发送主机发送一个本地的RARP广播，在此广播包中，声明自己的MAC地址并且请求任何收到此请求的RARP服务器分配一个IP地址。
- 本地网段上的RARP服务器收到此请求后，检查其RARP列表，查找该MAC地址对应的IP地址。
- 如果存在，RARP服务器就给源主机发送一个响应数据包并将此IP地址提供给对方主机使用。
- 如果不存在，RARP服务器对此不做任何的响应。
- 源主机收到从RARP服务器的响应信息，就利用得到的IP地址进行通讯；如果一直没有收到RARP服务器的响应信息，表示初始化失败。
- 协议解析(它的内容是和ARP协议非常类似的)
- 类似于ARP的报文格式主要差别在于帧类型代码为0x8035（ARP为0x0806），操作码为3请求（ARP为1），4应答（ARP为2）。
4 ICMP协议 （I send or receive queries or error message）
- 基本介绍
- ICMP，全称是 Internet Control Message Protocol，即互联网控制报文协议，所谓控制，就是通过下发指令来感知和控制网络环境，所以它一定是配合一个无法感知网络环境的协议来工作的，这个协议就是 IP(包括 IPv4 和 IPv6)。所以，ICMP 通常被认为是 IP 协议的一部分，它封装在 IP 层中，使用 IP 协议进行传输。因此，严格来说，ICMP 既不是一个网络层协议，也不是一个传输层协议，而是介于两者之间的一个协议。
- 它的主要功能是传输网络诊断信息，信息主要包括两类：
- 一类是 查询类报文 ：主要用于信息的查询和采集，比如采集传输路径上的每个路由器都是谁，本次传输的报文是否达到目的地等等。
- 另一类是 差错诊断类报文 ：主要用于诊断网络故障，比如传输报文被丢弃的原因是什么等等。
- 为什么需要 ICMP
- 我们都知道，IP 协议是一个不可靠协议，如果 IP 包在传输过程中出现错误，比如 checksum 对不上，拥塞，超时等等，那么 IP 包是会直接被丢弃的，之后也不会有进一步的努力来修正。这是 IP 协议的一个设计准则决定的，也就是 best effort，尽力而为，这样的好处是让 IP 协议尽量保持简单的形态，只负责有效率的数据传输，而更多的质量控制交给高层的协议去处理(比如 TCP)。但高层能提供质量控制的协议毕竟在少数，所以就需要在下层有协议来辅助 IP 完成必要的网络质量管理。ICMP 协议自然就被提出来了。
- 通过 ICMP 协议，当 IP 包发生错误的时候，上层发送 IP 包的主机或路由器并不知道下层发生了错误，这个时候，下层的主机或路由器就可以通过发送 ICMP 包，将错误信息汇报给上层，从而让上层的主机或路由器进行调整。不过需要注意的是，ICMP 仅仅只能提供某些特定类型的错误信息汇报，并不能帮助 IP 协议成为可靠的协议。它能做的事还是有限，但用于基本的网络质量管理是足够了。
- ICMP 报文格式
-
如下图所示，ICMP 报文是被封装在 IP 数据报中传输的。
-
-
IP 报头中的 Protocol 字段为 1 即表示该报文携带的是 ICMP 报文。
-
进一步看，ICMP 报头为 4 个字节：
-
- 类型 type：占 1 个字节，表示较大范围类型分类的 ICMP 报文
- 代码 code：占 1 个字节，表示较小范围类型分类的 ICMP 报文(type的细分)
- 校验和 checksum：占 2 个字节，ICMP checksum 的计算方法类似于 IP checksum，但是不同的是 IP 只校验头部，ICMP 校验头部+数据部分
- 后面紧接的 ICMP 数据部分，根据前面的类型和代码字段的不同，具有不同的内容。
-
第一张表：常见的一些类型(type)表
类型 内容 种类 解释 0 应答 R ping应答 3 目的不可达 E 很多细分，如主机协议 4 源端抑制 E 表示拥塞 5 重定向 E 表示最优的路由路径 8 请求 R ping请求 9 路由器通告 R 告知路由器地址 10 路由器请求 R 请求路由器通告 11 超时 E TTL=0 12 参数问题 E 有问题的报文 R表示查询报文，E表示差错报文
-
第二张表：类型细分表
类型 代码 内容 解释 3 0 网络不可达 没有路由到目的地 3 1 主机不可达 已知但不可达的主机 3 2 协议不可达 未知协议 3 3 端口不可达 未知端口 3 4 要分片但设置了不分片位 路由器MTU限制需要分片但无法分片 3 5 源路由失败 中间跳不可达 3 13 管理禁止通信 被过滤策略禁止的通信 3 14 违反主机优先级 src/dst/port不准许的优先级 3 15 优先级终止生效 在最小Tos之下 5 1 主机重定向数据报 指示一个可选的路由器/主机 11 0 在传输期间时间超时 重组计时器超市之前，有分片未到达 12 0 指针指示差错 字节偏移量指示第一个问题字段 12 2 错误的长度 数据包有无效的Total Length 字段
-
-
难点讲解
- 源端抑制
- 属于差错信息。如果某个源主机向目的主机快速地发送数据包，但目的主机来不及处理，就会向源主机发出该类型的 ICMP 包，提醒源主机放慢发送速度。
- 重定向
- 属于差错信息。如果某个源主机向网络中发送一个 IP 包，路径中某个路由器收到这个 IP 包，对照其路由表，发现自己不应该接收该包(包需要原路返回，或者不是最佳路由路径)，就会向源主机发送该类型的 ICMP 包，提醒源主机修改自己的路由表，下次路由到另外一个更好的路由器。
- 需要分片但设置了不分片位
- 属于差错信息。如果某个源主机在发送一个 IP 包之前，对该 IP 包中的首部字段 DF 位设为 1，也就是“分片禁止位=1”，表示该包在传输的过程中不允许分片，但是中间某个路由器允许传输的最大路径 MTU 小于该包大小，需要分片才能传输，但是由于设置不分片位，路由器会将该包丢弃，并向源主机发送一个携带 MTU 信息的 ICMP 包，提醒源主机下次发包的大小不应超过该 MTU 的值。这种类型的 ICMP 包通常用来发现传输路径上的 MTU 值。
- TTL超时
- 属于差错信息。超时定义了数据包在网络中存活的最长时间，IPv4 中的 TTL 字段和 IPv6 中的 Hop Limit 字段都表示了这层意思，它们是一个整数值，会随着经过的路由器而递减，当减为 0 时，就认为该 IP 包超时，然后当前减为 0 的路由器会向源主机发送 ICMP 包，通知它发生了超时错误。
- 源端抑制
-
- 有哪些命令体现了 ICMP
- ping 使用查询类型报文
- traceroute 使用差错类型报文
- Ping 原理分析
- ping使用的是 ICMP 的请求回显/回显应答类型的报文，格式如下。它的内容包括标识符、序列号以及回显数据3部分，报文大小默认为 64 字节(header的8字节+body的56字节)。
- ICMP回显报文格式
1.
- 请求回显类型是8，回显应答类型是0，他们代码都是 0，校验和是包内容根据算法生成用于校验数据完整性。
- 标识符在 Linux/macOS 中用的是进程ID。
- 序列号在 Linux/macOS 中是从0递增的，每个进程独立的。
- 回显数据包括发送ping请求的时间戳(在macOS占8字节，在Linux占16字节)，以及一串填充数据，共48字节。填充数据你也可以通过 -p pattern指定，比如 ping -pff 192.168.33.10，则填充数据全部是 ff。
- 默认TTL是64，你可以通过 -t ttl 指定TTL值。
- ping请求时间 = 接收到回显应答的时间 - 应答回显数据中的时间
- 实例测试
-
-
Ping请求
-
Ping响应
-
描述
Internet Control Message Protocol Type: 8 (Echo (ping) request) // ICMP类型为8，说明这是一个ICMP请求查询报文 Code: 0 //表示是请求 Checksum: 0xf7e9 [correct] //校验和 [Checksum Status: Good] //校验和状态，good表示校验和正确，bad表示数据报被修改或者发生错误 Identifier (BE): 1 (0x0001) //标识，用于区分在linux下抓包，基本上抓的每一个ICMP包都是1 Identifier (LE): 256 (0x0100) //标识，用于区分在windows下抓包，基本上抓的每一个ICMP包都是256 Sequence number (BE): 21 (0x0015) //用于区分在linux下抓包，每一个ICMP包的都不一样 Sequence number (LE): 5376 (0x1500) //用于区分在windows下抓包，每一个ICMP包的都不一样 [No response seen] Data (48 bytes) //数据部分
-
- 如何自己写一个ping？可以参考下这位朋友的ping工具的 python实现。 ping Python3实现
- Traceroute 原理分析
- traceroute 是类 Linux 系统自带的工具，Windows 上类似的工具是 tracert，两者有些许不同，tracert 默认使用 ICMP 报文探测，而 traceroute 默认使用 UDP，但是也可以使用 TCP/ICMP 三种报文探测。
- traceroute 利用 ICMP 差错报文，主要用来确定这几件事：
- 确定通信双方路径上经过的路由器设备
- 确定 UDP 包是否成功达到目的地
- 发现路径 MTU
- traceroute 用到ICMP协议和TTL字段。TTL字段是数据报的生存周期，初始值通常默认是64，每个处理数据报的路由器都需要把TTL值减去1或者数据报在路由器停留的秒数(因为绝大多数路由器转发数据报时延都小于1秒，因此通常都是减去1，而且很多路由器的实现即便超过1秒也是减去1，因此可以把TTL看做一个跳站计数器)。路由器接收到一份IP数据报时，如果TTL为0或者1，则路由器不转发该数据报，而是丢弃并给源机器发送一份ICMP超时报文，而ICMP信息中的IP报文中源地址正是路由器的IP地址。
- traceroute的原理
- 先发送一份TTL为1的报文，这样第一个路由器会将TTL减1然后丢弃该报文，并发回一个ICMP超时报文，这样就得到了第一个路由器的IP地址；接着发送一个TTL为2的报文，可以得到第二个路由器的IP地址；继续该过程直到目的主机。但是目的主机即便收到TTL为1的报文，它也不会丢弃该数据报并发回一份ICMP超时报文，因为此时数据报已经到了目的地。为了判断是否到达目的主机，traceroute发送的报文采用了UDP数据报，它选择一个很大的端口值如30000以上的，以保证没有其他应用程序使用该端口，然后目的主机会返回一个端口不可达的ICMP报文，这样就可以知道什么时候结束。
- traceroute针对每个TTL会发3次UDP报文，并打印每次的往返时间。如果5秒内没有收到3次报文中任何一个的响应，则打印*号继续下一个TLL的报文发送。3次报文选择的UDP目的端口分别是 33435，33436，33437，UDP报文数据长度为24字节，内容为全0(macOS环境)。
4.2.6 传输层协议
1 UDP协议
- 基本介绍
- 与IP的区别：UDP在IP数据报服务之上增加了两个最基本的服务：复用和分用 + 差错检测
- 常用于一次性传输较少数据的网络应用，如DNS 、SNMP等
- 因为对于这些应用，若采用TCP，则将为连接创建、维护、拆除带来不小的开销
- 常用于多媒体应用(IP电话、视频会议、流媒体等）
- 因为可靠传输对于这些应用来说不是最重要的，TCP的拥塞控制会导致数据出现较大的延迟，这是大忌！
- 不保证可靠交付，但并不意味着应用对数据的要求是不可靠的，所有维护可靠性的工作可由用户在应用层完成
- 面向报文的，报文不可分割，是UDP数据报处理的最小单位
- UDP的优点
- 无需建立连接，不会引入建立连接的时延
- DNS如果运行在TCP上，速度会慢很多；因此使用UDP
- HTTP使用TCP是因为对于基于文本数据的web网页，可靠性是至关重要的
- 无连接状态，不维护连接状态，一般能支持更多的活动客户机
- TCP需要在端系统中维护连接状态（包括接收和发送缓存、拥塞控制参数和序号与确认号的参数）
- 分组首部开销小
- TCP有20B的首部开销，UDP有8B的开销
- 没有拥塞控制，应用层能更好地控制要发送的数据和发送时间
- UDP没有拥塞控制，因此网络中的拥塞不会影响主机的发送效率
- 支持一对一、一对多、多对一和多对多的交互通信
- 无需建立连接，不会引入建立连接的时延
- UDP报文格式
- UDP数据报包含两部分：UDP首部和用户数据
- UDP首部(8Byte)，由4个字段组成，每个字段长度为2Byte
- 源端口号：在需要对方回信时选用，不需要时全0
- 目的端口号：这在终点交付报文时必须使用到
- UDP长度：UDP数据报的长度(包括首部和数据)，其最小值是8(仅有首部)
- 校验和：检测UDP数据报中是否有错，有错就丢弃。该字段可选，不使用时全0
- 当传输层从IP层收到UDP数据报时，就根据首部中的目的端口，把UDP数据报通过相应的端口上交给应用进程，如下图所示：
- 如果接收方UDP发现收到的报文中的目的端口号不正确（即不存在对应于端口号的应用进程），那么就丢弃该报文，并由ICMP发送“端口不可达”差错报文给发送方
- UDP校验
- 在计算校验和时，要在UDP数据报之前增加12Byte的伪首部，伪首部并不是UDP的真正首部，只是在计算校验和时，临时添加在UDP数据报的前面，得到一个临时的UDP数据报
- UDP校验和检查首部和数据部分，而IP校验和只检查数据报的首部
- UDP的伪首部
- 伪首部的特点
- 长度为12Byte
- 伪首部不是UDP的真正首部，只在计算校验和时用到
- 伪首部既不向下传送也不向上递交，只是为了计算校验和
- 伪首部结构
- 伪首部的特点
3. UDP校验方法：
1. 发送方首先把全零放入校验和字段并添加伪首部，然后把UDP数据报视为许多16位的字连接起来。
1. 若UDP数据报的数据部分不是偶数个字节，则要在数据部分末尾增加一个全零字节（但此字节不发送）。
1. 接下来按二进制反码计算出这些16位字的和，并将此和的二进制反码写入校验和字段。
1. 接收方把收到的UDP数据报加上伪首部（如果不为偶数个字节，那么还需要补上全零字节）后，按二进制反码计算出这些16位字的和。
1. 当无差错时其结果应全为1，否则表明有差错出现，接收方就应该丢弃这个UDP数据报。
2 TCP协议
-
基本介绍
- 传输控制协议（TCP，Transmission Control Protocol）是一种面向连接的、可靠的、基于字节流的传输层通信协议。
-
特点
- 基于连接的：数据传输之前需要建立连接
- 全双工的：可以双向传输
- 字节流：不限制数据大小，打包成报文段，保证有序接收，重复报文自动丢弃
- 流量缓冲：解决双方处理能力的不匹配
- 可靠的传输服务：保证可达，丢包时通过重发机制实现可靠性
- 拥塞控制：防止网络出现恶性拥塞
-
为满足TCP协议的这些特点，TCP协议做了以下规定：
- ①数据分片：在发送端对用户数据进行分片，在接收端进行重组，由TCP确定分片的大小并控制分片和重组
- ②到达确认：接收端接收到分片数据时，根据分片数据序号向发送端发送一个确认
- ③超时重发：发送方在发送分片时启动超时定时器，如果在定时器超时之后没有接收到对应的确认，重发分片
- ④滑动窗口：TCP连接每一方的接收缓冲空间大小都固定，接收端只允许另一端发送接收端缓冲区所能接纳的数据，TCP在滑动窗口的基础上提供流量控制，防止较快主机致使较慢主机的缓冲区溢出
- ⑤失序处理：作为IP数据报来传输的TCP分片到达时可能会失序，TCP将对接收的数据进行重新排序，将接收到的数据以正确的顺序交给应用层
- ⑥重复处理：作为IP数据报来传输的TCP分片会发生重复，TCP的接收端必须丢弃重复的数据
- ⑦数据校验：TCP将保持它首部和数据的校验和，这是一个端到端的校验和，目的是检测数据在传输过程中的任何变化。如果收到分片的校验和由差错，TCP将丢弃这个分片，并确认接收到此报文段导致对端超时并重发
-
TCP协议的报文格式
- TCP传送的数据单元称为报文段。
- TCP报文段既可以用来运载数据，又可以用来建立连接、释放连接和应答。
- 一个TCP报文段分为首部和数据两部分，整个TCP报文段作为IP数据报的数据部分封装在IP数据报中。
-
字段解释
- 源端口号：报文的发送端口【端口是传输层与应用层的服务接口；传输层的多路复用/分用都要通过端口实现】
- 目的端口号：报文的接受端口
- 序号(seq)（范围0～2^32-1）：是本报文段所发送的数据项目组第一个字节的序号。在TCP传送的数据流中，每一个字节都有一个序号。例如，一报文段的序号为300，而且数据共100字节，则下一个报文段的序号就是400；序号是32bit的无符号数，序号到达（2的32次-1）后从0开始。
- 确认序号(ack)：是期望收到对方下次发送的数据的第一个字节的序号，也就是期望收到的下一个报文段的首部中的序号；确认序号应该是上次已成功收到数据字节序号+1（若确认号为N，则表明到序号N-1为止的所有数据都已正确收到），只有ACK标志为1时，确认序号才有效。例如，B正确收到了A发送过来的一个报文段，其序号字段是501，而数据长度是200B（序号501~700），这表明B正确收到了A发送的到序号700为止的数据。因此B期望收到A的下一个数据序号是701，于是B在发送给A的确认报文段中把确认号置为701。
- 数据偏移：占4比特，表示数据开始的地方离TCP段的起始处有多远。实际上就是TCP段首部的长度。由于首部长度不固定，因此数据偏移字段是必要的。数据偏移”的单位是32位(以4B为计算单位)。因此当此字段的值为15时，达到TCP首部的最大长度60B。
- 保留：6比特，供以后应用，现在置为0。
- 6个标志位比特
- 紧急位URG(占1位)：URG=1时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送（相当于高优先级的数据。但URG需要和紧急指针配合使用，即数据从第一个字节到紧急指针所指字节就是紧急数据。
- 确认位ACK(占1位)：仅当ACK=1时确认号字段才有效。当ACK=0时，确认号无效。TCP规定，在连接建立后所有传送的报文段都必须把ACK置1。
- 推送位PSH(占1位)：接收方TCP收到PSH=1的报文段，就尽快地交付给接收应用进程，而不再等到整个缓存都填满后再向上交付。
- 复位位RST(占1位)：RST=1时，表明TCP连接中出现严重差错（如主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接。复位比特还用来拒绝一个不法的报文段或拒绝打开一个连接。
- 同步位SYN(占1位)：同步SYN=1表示这是一个连接请求或连接接受报文。当SYN=1，ACK=0时，表明这是一个连接请求报文，对方若同意建立连接，则应在响应报文中使用SYN=1,ACK=1。
- FIN：终止位FIN(占1位)：用来释放一个连接。当FIN=1时，表明此报文段的发送方的数据已发送完毕，并要求释放传输连接。
- 窗口（范围为0-2^16-1 ）：TCP通过滑动窗口的概念来进行流量控制。设想在发送端发送数据的速度很快而接收端接收速度却很慢的情况下，为了保证数据不丢失，显然需要进行流量控制， 协调好通信双方的工作节奏。所谓滑动窗口，可以理解成接收端所能提供的缓冲区大小。TCP利用一个滑动的窗口来告诉发送端对它所发送的数据能提供多大的缓冲区。窗口大小为字节数起始于确认序号字段指明的值（这个值是接收端正期望接收的字节）。窗口大小是一个16bit字段，因而窗口大小最大为65535字节。例如，设确认号是701，窗口字段是1000。这表明，从701号算起，发送此报文段的一方还有接收1000字节数据（字节序号为701~1700）的接收缓存空间。
- 检验和：检验和覆盖了整个TCP报文段：TCP首部和数据。这是一个强制性的字段，一定是由发端计算和存储，并由收端进行验证。在计算校验和时，和UDP一样，要在TCP报文段的前面加上12B的伪首部（只需将UDP伪首部的第4个字段，即协议字段的17改成6，其他的和UDP一样）
- 紧急指针：只有当URG标志置1时紧急指针才有效。**它指出在本报文段中紧急数据共有多少字节，**紧急指针是一个正的偏移量，和序号字段中的值相加表示紧急数据最后一个字节的序号。
- 选项(长度可变)：TC最初只规定了一种选项，即最大报文段长度（Maximum Segment Size，MSS）。MSS是TCP报文段中的数据字段的最大长度（注意仅仅是数据字段）。
- 填充：这是为了使整个首部长度是4B的整数倍。
-
TCP连接管理
- 在TCP连接建立的过程中，要解决以下三个问题：
- 要使每一方能够确知对方的存在。
- 要允许双方协商一些参数（如最大窗口值、是否使用窗口扩大选项、时间戳选项及服务质量等）。
- 能够对运输实体资源（如缓存大小、连接表中的项目等）进行分配。
- TCP连接的端口即为套接字（socket）或插口，每条TCP连接唯一地被通信的两个端点（即两个套接字）确定。
- TCP连接的建立采用客户/服务器方式。主动发起连接建立的应用进程称为客户（Client），而被动等待连接建立的应用进程称为服务器（Server）。
- 在TCP连接建立的过程中，要解决以下三个问题：
-
TCP连接建立–三次握手
- 参考：TCP三次握手和四次挥手** ||| **TCP协议
- 建立连接
- TCP是因特网中的传输层协议，使用三次握手协议建立连接。当主动方发出SYN连接请求后，等待对方回答SYN+ACK，并最终对对方的SYN执行ACK确认。这种建立连接的方法可以防止产生错误的连接，TCP使用的流量控制协议是可变大小的滑动窗口协议。
- TCP三次握手的过程如下：
- 第一次握手：Client进入SYN_SENT状态，发送一个SYN帧来主动打开传输通道，该帧的SYN标志位被设置为1，同时会带上Client分配好的SN序列号，该SN是根据时间产生的一个随机值，通常情况下每间隔4ms会加1。除此之外，SYN帧还会带一个MSS（最大报文段长度）可选项的值，表示客户端发送出去的最大数据块的长度。
- 第二次握手：Server端在收到SYN帧之后，会进入SYN_RCVD状态，同时返回SYN+ACK帧给Client，主要目的在于通知Client，Server端已经收到SYN消息，现在需要进行确认。Server端发出的SYN+ACK帧的ACK标志位被设置为1，其确认序号AN（Acknowledgment Number）值被设置为Client的SN+1；SYN+ACK帧的SYN标志位被设置为1，SN值为Server端生成的SN序号；SYN+ACK帧的MSS（最大报文段长度）表示的是Server端的最大数据块长度。
- 第三次握手：Client在收到Server的第二次握手SYN+ACK确认帧之后，首先将自己的状态会从SYN_SENT变成ESTABLISHED，表示自己方向的连接通道已经建立成功，Client可以发送数据给Server端了。然后，Client发ACK帧给Server端，该ACK帧的ACK标志位被设置为1，其确认序号AN（Acknowledgment Number）值被设置为Server端的SN序列号+1。还有一种情况，Client可能会将ACK帧和第一帧要发送的数据，合并到一起发送给Server端。
- Server端在收到Client的ACK帧之后，会从SYN_RCVD状态会进入ESTABLISHED状态，至此，Server方向的通道连接建立成功，Server可以发送数据给Client，TCP的全双工连接建立完成。
- 三次握手的图解
- 第一次握手：Client将同步标志位SYN置为1（SYN为1就表示要建立连接，连接成功之后该位置会再次被置为0），请求序号seq=x（在所有的字节排列中，申请从哪一个字节开始发送，这个序号就一般表示当前已经发送到哪个序号，服务器同意后将会从下一个序号开始发送，第一次握手只有请求序号没有确认号），并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。
- 第二次握手：Server收到数据包后由同步标志位SYN=1知道Client请求建立连接，确认标志位ACK置为1（这会才有确认标志位，第一次握手并没有确认标志位。当确认标志位为0时，确认号不起作用），ack=x+1（确认序号等于请求序号+1，表示x+1之前的Server都收到了，从Server发送的请求已经收到）。TCP是全双工协议，因此Server有可能也会给Client发送数据，因此Server也会向Client建立连接，Server将同步标志位SYN置为1（Server也要向Client发送请求，因此SYN也要被置为1），seq=y就表示Server给Client发送的数据开始序号。并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。
- 第三次握手：因为连接要是双向的，Server确认后只是Client到Server连通了，因此Client也要确认一下，才能让Server向Client的连接也连通。Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。
-
TCP释放连接–四次挥手
- 所谓四次挥手（Four-Way Wavehand）即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端相互总共发送4个包以确认连接的断开。在socket编程中，这一过程由客户端或服务端任一方执行close来触发。
- 四次挥手的图解
- 由于TCP连接是全双工的，因此，每个方向都必须要单独进行关闭。这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了。但是在这个TCP连接上仍然能够发送数据，直到另一方向也发送了FIN。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭，上图描述的即是如此。
- 第一次挥手：Client发送一个FIN，以及选择号seq=u（表示：u之前的数据已经全部发送，并且数据发到u就可以截止了，就不再有数据了），用来关闭Client到Server的数据传送。Client进入FIN_WAIT_1状态。
- 第二次挥手：Server收到FIN后，发送一个请求号seq=v和确认序号ack=u+1给Client。Server进入CLOSE_WAIT状态。
- 第三次挥手：Server发送一个FIN，请求号为最新的seq=w和确认序号ack=u+1，用来关闭Server到Client的数据传送。Server进入LAST_ACK状态。
- 第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为w+1。Server进入CLOSED状态，完成四次挥手。
四次挥手的情景大致是这样的：
1、客户端主机C说：“我没有数据了，断开连接吧。 ”
2、服务器S说：“好，但是我还有数据（不断给C发送数据，此时C已经不能给S发送数据了，
但是必须要求收S发来的数据）。”
3、（当S给C发完数据后）S说：“我发完了，断开连接吧。”
4、C说：“好，断开连接吧。”
- 为什么建立连接是三次握手，而关闭连接却是四次挥手呢？
- 这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方是否现在关闭发送数据通道，需要上层应用来决定，因此，己方ACK和FIN一般都会分开发送。
- 因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。
- 三次握手期间，为什么TCP客户端最后还要发送一次确认呢？
- 一句话，主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。
- 如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。
- 为什么要三次握手？
- 为了防止已失效的连接请求报文突然又传送到了服务端，因为产生错误。
- 具体解释： “已失效的连接请求报文段”产生情况：
- client 发出的第一个连接请求报文段并没有丢失，而是在某个网络节点长时间滞留，因此导致延误到连接释放以后的某个时间才到达 service。如果没有三次握手，那么此时server收到此失效的连接请求报文段，就误认为是 client再次发出的一个新的连接请求，于是向 client 发出确认报文段，同意建立连接，而此时 client 并没有发出建立连接的情况，因此并不会理会服务端的响应，而service将会一直等待client发送数据，因此就会导致这条连接线路白白浪费。
- 具体解释： “已失效的连接请求报文段”产生情况：
- 如果此时变成两次挥手行不行？
- 这个时候需要明白全双工与半双工，再进行回答。比如：
- 第一次握手： A给B打电话说，你可以听到我说话吗？第二次握手： B收到了A的信息，然后对A说： 我可以听得到你说话啊，你能听得到我说话吗？第三次握手： A收到了B的信息，然后说可以的，我要给你发信息啦！
- 这个时候需要明白全双工与半双工，再进行回答。比如：
- 在三次握手之后，A和B都能确定这么一件事： 我说的话，你能听到； 你说的话，我也能听到。 这样，就可以开始正常通信了，如果是两次，那将无法确定。
- 为了防止已失效的连接请求报文突然又传送到了服务端，因为产生错误。
- 为什么要四次挥手？
- MSL：报文段最大生存时间，它是任何报文段被丢弃前在网络内的最长时间
- 原因如下：
- 保证TCP协议的全双工连接能够可靠关闭保证这次连接的重复数据从网络中消息。
- 第一点： 如果主机1直接 关闭，由于IP协议的不可靠性或者其他网络原因，导致主机2没有收到主机1最后回复的 ACK。那么主机2就会在超时之后继续发送 FIN，此时由于主机1已经关闭，就找不到与重发的 FIN 对应的连接。所以，主机1 不是直接进入 关闭，而是TIME_WAIT 状态。当再次收到 FIN 的时候，能够保证对方收到 ACK ，最后正确关闭连接。
- 第二点：如果主机1直接 关闭，然后又再向主机 2 发起一个新连接，我们不能保证这个新连接与刚才关闭的连接端口是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题，但还是有特殊情况出现；假设新连接和已经关闭的老连接端口号是一样的，如果前一次连接的某些数据仍然滞留在网络中( Lost Duplicate )，那些延迟数据在建立新连接之后才到达主机2，由于新连接和老连接的端口号是一样的，TCP 协议就认为哪个延迟的数据时属于新连接的，这样就和真正的新连接的数据包发生混淆了。所以TCP连接要在 TIME_WAIT 状态等待两倍 MSL ，保证本次连接的所有数据都从网络中消失。
- TCP四次挥手期间，为什么要等待呢？
- 为了这种情况： B向A发送 FIN = 1 的释放连接请求，但这个报文丢失了， A没有接到不会发送确认信息， B 超时会重传，这时A在 WAIT_TIME 还能够接收到这个请求，这时再回复一个确认就行了。（A收到 FIN = 1 的请求后 WAIT_TIME会重新记时）
- 另外服务器B存在一个保活状态，即如果A突然故障死机了，那B那边的连接资源什么时候能释放呢？ 就是保活时间到了后，B会发送探测信息， 以决定是否释放连接
- TCP四次挥手期间，为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？
- 原因有二：
- 一、保证TCP协议的全双工连接能够可靠关闭
- 第一点，如果Client直接CLOSED了，那么由于IP协议的不可靠性或者是其它网络原因，导致Server没有收到Client最后回复的ACK。那么Server就会在超时之后继续发送FIN，此时由于Client已经CLOSED了，就找不到与重发的FIN对应的连接，最后Server就会收到RST而不是ACK，Server就会以为是连接错误把问题报告给高层。这样的情况虽然不会造成数据丢失，但是却导致TCP协议不符合可靠连接的要求。所以，Client不是直接进入CLOSED，而是要保持TIME_WAIT，当再次收到FIN的时候，能够保证对方收到ACK，最后正确的关闭连接。
- 二、保证这次连接的重复数据段从网络中消失
- 第二点，如果Client直接CLOSED，然后又再向Server发起一个新连接，我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题，但是还是有特殊情况出现：假设新连接和已经关闭的老连接端口号是一样的，如果前一次连接的某些数据仍然滞留在网络中，这些延迟数据在建立新连接之后才到达Server，由于新连接和老连接的端口号是一样的，又因为TCP协议判断不同连接的依据是socket pair，于是，TCP协议就认为那个延迟的数据是属于新连接的，这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME_WAIT状态等待2倍MSL，这样可以保证本次连接的所有数据都从网络中消失。
- 一、保证TCP协议的全双工连接能够可靠关闭
- 原因有二：
1832
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
