以太网通讯报文详解
以太网通讯报文详解
来源：编程帮，http://c.biancheng.net/view/6385.html
1、物理层协议有：EIA/TIA-232， EIA/TIA-499，V.35， V.24，RJ45， Ethernet， 802.3
2、数据链路层协议有：Frame Relay，HDLC，PPP， IEEE 802.3/802.2
3、网络层协议有：IP，IPX，AppleTalk DDP
4、传输层协议有：TCP，UDP，SPX，ICMP
5、会话层协议有：RPC，SQL，NFS，NetBIOS，names，AppleTalk
6、表示层协议有：TIFF，GIF，JPEG，PICT，ASCII，EBCDIC，encryption
7、应用层协议有：FTP，WWW，Telnet，NFS，SMTP，Gateway，SNMP，HTTP
物理层
详细见：https://www.cnblogs.com/qishui/p/5449783.html
(1)MII(介质无关接口)和RS（协调子层）
MII：依赖物理层功能和不依赖物理层功能的分界接口
RS：负责处理MII信令与MAC子层翻译或映射需求的一个特殊子层（相当于物理层顶层）
(2)PCS(物理编码子层)
从名称来看，本层将主要从事编码相关工作；
以CAN总线为例，为了实现同步，CAN总线会在每五个0穿插一个1。
而在PCS中，则会采用4B/5B编码的方式，来进行转换，来避免常规数据传输过程中产生的不平衡。另外PCS还可以采用加扰的方式，将传输的数据，转化成便于接受的形式。
(3)PMA(物理媒介附加)——也被称为串行器或者解串器
本层主要作用是将数据在两种不大相同的形式上转换（采用一次一比特的方式），这有助于多个下层子层（PMD）对不同媒介的支持.另外，PMA也具有时钟恢复和媒介冲突检测的功能。
(4)PMD
从PMA读取数据并且执行电路信号转换。
或者是读取电路信号，将其转化为比特流传入PMA子层。
(5)MDI
通常为控制器和线缆之间的接口。
数据链路层
以太网数据帧格式
以太网链路传输的数据包称做以太帧，或者以太网数据帧。在以太网中，网络访问层的软件必须把数据转换成能够通过网络适配器硬件进行传输的格式。
以太帧的工作机制
当以太网软件从网络层接收到数据报之后，需要完成如下操作：
1) 根据需要把网络层的数据分解为较小的块，以符合以太网帧数据段的要求。以太网帧的整体大小必须在 64～1518 字节之间（不包含前导码）。有些系统支持更大的帧，最大可以支持 9000 字节。
2) 把数据块打包成帧。每一帧都包含数据及其他信息，这些信息是以太网网络适配器处理帧所需要的。
3) 把数据帧传递给对应于 OSI 模型物理层的底层组件，后者把帧转换为比特流，并且通过传输介质发送出去。
4) 以太网上的其他网络适配器接收到这个帧，检查其中的目的地址。如果目的地址与网络适配器的地址相匹配，适配器软件就会处理接收到的帧，把数据传递给协议栈中较高的层。
以太帧的结构
以太帧起始部分由前同步码和帧开始定界符组成，后面紧跟着一个以太网报头，以 MAC 地址说明目的地址和源地址。以太帧的中部是该帧负载的包含其他协议报头的数据包，如 IP 协议。
以太帧由一个 32 位冗余校验码结尾，用于检验数据传输是否出现损坏。以太帧结构如图所示。
上图中每个字段的含义如下表所示：
- 前同步码：用来使接收端的适配器在接收 MAC 帧时能够迅速调整时钟频率，使它和发送端的频率相同。前同步码为 7 个字节，1 和 0 交替。
- 帧开始定界符：帧的起始符，为 1 个字节。前 6 位 1 和 0 交替，最后的两个连续的 1 表示告诉接收端适配器：“帧信息要来了，准备接收”。
- 目的地址：接收帧的网络适配器的物理地址（MAC 地址），为 6 个字节（48 比特）。作用是当网卡接收到一个数据帧时，首先会检查该帧的目的地址，是否与当前适配器的物理地址相同，如果相同，就会进一步处理；如果不同，则直接丢弃。
- 源地址：发送帧的网络适配器的物理地址（MAC 地址），为 6 个字节（48 比特）。
- 类型：上层协议的类型。由于上层协议众多，所以在处理数据的时候必须设置该字段，标识数据交付哪个协议处理。例如，字段为 0x0800 时，表示将数据交付给 IP 协议。
- 数据：也称为效载荷，表示交付给上层的数据。以太网帧数据长度最小为 46 字节，最大为 1500 字节。如果不足 46 字节时，会填充到最小长度。最大值也叫最大传输单元（MTU）。
在 Linux 中，使用 ifconfig 命令可以查看该值，通常为 1500。
帧检验序列 FCS 检测该帧是否出现差错，占 4 个字节（32 比特）。发送方计算帧的循环冗余码校验（CRC）值，把这个值写到帧里。接收方计算机重新计算 CRC，与 FCS 字段的值进行比较。如果两个值不相同，则表示传输过程中发生了数据丢失或改变。这时，就需要重新传输这一帧。
以太帧报文格式
ARP协议寻址
ARP协议的工作机制
ARP 是"Address Resolution Protocol"的缩写，译为"地址解析协议"，它是根据 IP 地址获取物理地址的一个 TCP/IP 协议。
ARP 协议通过 IP 地址向 MAC 地址的转换，解决网际层和网络访问层的衔接问题。
由于 IP 地址和 MAC 地址定位方式不同，ARP 协议成为数据传输的必备协议。主机发送信息前，必须通过 ARP 协议获取目标 IP 地址对应的 MAC 地址，才能正确地发送数据包。
(1) 为什么需要 ARP 协议
在网络访问层中，同一局域网中的一台主机要和另一台主机进行通信，需要通过 MAC 地址进行定位，然后才能进行数据包的发送。
而在网络层和传输层中，计算机之间是通过 IP 地址定位目标主机，对应的数据报文只包含目标主机的 IP 地址，而没有 MAC 地址。
因此，在发送之前需要根据 IP 地址获取 MAC 地址，然后才能将数据包发送到正确的目标主机，而这个获取过程是通过 ARP 协议完成的。
(2) ARP 工作的基本流程
ARP 工作流程分为两个阶段，一个是 ARP 请求过程，另一个是 ARP 响应过程。
工作流程如下所示。
在上面图片中，主机 A 的 IP 地址为 192.168.1.1，主机 B 的 IP 地址为 192.168.1.2。
主机 A 与主机 B 进行通信，需要获取其 MAC 地址，基本流程如下：
主机 A 以广播形式向网络中所有主机发送 ARP 请求，请求包中包含了目标 IP 地址 192.168.1.2。
主机 B 接收到请求，发现自己就是主机 A 要找的主机，返回响应，响应包中包含自己的 MAC 地址。
(3) ARP 缓存
在请求目标主机的 MAC 地址时，每次获取目标主机 MAC 地址都需要发送一次 ARP 请求，然后根据响应获取到 MAC 地址。
为了避免重复发送 ARP 请求，每台主机都有一个 ARP 高速缓存。当主机得到 ARP 响应后，将目标主机的 IP 地址和物理地址存入本机 ARP 缓存中，并保留一定时间。
只要在这个时间范围内，下次请求 MAC 地址时，直接查询 ARP 缓存，而无须再发送 ARP 请求，从而节约了网络资源。
当有了 ARP 缓存以后，ARP 的工作流程如下：
1) 主机 A 在本机 ARP 缓存中检查主机 B 的匹配 MAC 地址。
2) 如果在 ARP 缓存中没有找到主机 B 的 IP 地址及对应的 MAC 地址，它将询问主机 B 的 MAC 地址，从而将 ARP 请求帧广播到本地网络上的所有主机。源主机 A 的 IP 地址和 MAC 地址都包括在 ARP 请求中。
3) 本地网络上的每台主机都接收到 ARP 请求，并且检查是否与自己的 IP 地址匹配。如果主机发现请求的 IP 地址与自己的 IP 地址不匹配，它将丢弃 ARP 请求。主机 B 确定 ARP 请求中的 IP 地址与自己的 IP 地址匹配，则将主机 A 的 IP 地址和 MAC 地址映射添加到本地 ARP 缓存中。
4) 主机 B 将包含自身 MAC 地址的 ARP 回复消息直接发送给主机 A。
5) 当主机 A 收到从主机 B 发来的 ARP 回复消息时，会用主机 B 的 IP 地址和 MAC 地址更新 ARP 缓存。
6) 主机 B 的 MAC 地址一旦确定，主机 A 就能向主机 B 发送 IP 数据包。本机缓存是有生存期的，生存期结束后，将再次重复上面的过程。
(4) 查看 ARP 缓存
每次成功得到 ARP 响应以后，就会将 IP 地址对应的 MAC 地址添加到 ARP 缓存中。用户可以通过 arp 命令查看 ARP 缓存中的信息，并验证是否会将目标 IP 地址和 MAC 地址添加到 ARP 缓存中。
【示例】查看 ARP 缓存表并验证添加的 IP 地址和 MAC 地址。
1) 使用 arp 命令查看当前主机缓存信息，执行命令如下：
root@daxueba:~# arp -a
输出信息如下：
localhost (192.168.59.254) at 00:50:56:f7:9b:0d [ether] on eth0
localhost (192.168.59.2) at 00:50:56:ea:f3:a1 [ether] on eth0
上述输出信息表示当前 ARP 缓存中有两组信息，192.168.59.254 对应的 MAC 地址为 00：50：56：f7：9b：0d，192.168.59.2 对应的 MAC 地址为 00：50：56：ea：f3：a1。
2) 在当前主机上与主机 192.168.59.135 进行通信。例如，可以使用 ping 命令探测该主机。执行命令如下：
root@daxueba:~# ping 192.168.59.135
输出信息如下：
PING 192.168.59.135 (192.168.59.135) 56(84) bytes of data.
64 bytes from 192.168.59.135: icmp_seq=1 ttl=64 time=1.64 ms
64 bytes from 192.168.59.135: icmp_seq=2 ttl=64 time=0.420 ms
64 bytes from 192.168.59.135: icmp_seq=3 ttl=64 time=0.405 ms
64 bytes from 192.168.59.135: icmp_seq=4 ttl=64 time=0.343 ms
上述输出信息表示成功向目标主机 192.168.59.135 发送了 ping 请求并得到了响应。
3) 当前主机的 ARP 缓存将会添加目标主机的 IP 地址及 MAC 地址。再次查看当前主机缓存信息，执行命令如下：
root@daxueba:~# arp -a
localhost (192.168.59.135) at 00:0c:29:ca:e4:66 [ether] on eth0
localhost (192.168.59.254) at 00:50:56:f7:9b:0d [ether] on eth0
localhost (192.168.59.2) at 00:50:56:ea:f3:a1 [ether] on eth0
上述输出信息中加粗部分为添加到 ARP 缓存中的目标主机的 IP 地址和 MAC 地址信息。
ARP 报文格式
ARP 协议是通过报文进行工作的，ARP 报文格式如图所示。
ARP 报文总长度为 28 字节，MAC 地址长度为 6 字节，IP 地址长度为 4 字节。不够以太网传输最短字节60，剩余的用00填充。
其中，每个字段的含义如下。
- 硬件类型：指明了发送方想知道的硬件接口类型，以太网的值为 1。
- 协议类型：表示要映射的协议地址类型。它的值为 0x0800，表示 IP 地址。
- 硬件地址长度和协议长度：分别指出硬件地址和协议的长度，以字节为单位。对于以太网上 IP 地址的ARP请求或应答来说，它们的值分别为 6 和 4。
- 操作类型：用来表示这个报文的类型，ARP 请求为 1，ARP 响应为 2，RARP 请求为 3，RARP 响应为 4。
- 发送方 MAC 地址：发送方设备的硬件地址。
- 发送方 IP 地址：发送方设备的 IP 地址。
- 目标 MAC 地址：接收方设备的硬件地址。
- 目标 IP 地址：接收方设备的IP地址。
ARP 数据包分为请求包和响应包，对应报文中的某些字段值也有所不同。
ARP 请求包报文的操作类型（op）字段的值为 request(1)，目标 MAC 地址字段的值为 Target 00：00：00_00：00：00(00：00：00：00：00：00)（广播地址）。
ARP 响应包报文中操作类型（op）字段的值为 reply(2)，目标 MAC 地址字段的值为目标主机的硬件地址。
PPP协议的帧格式
Cainv89 2016-02-04 11:53:30 45058 收藏 40
PPP帧各字段的意义
PPP帧的首部和尾部分别为四个字段和两个字段。
(1) PPP帧的首部
首部中的标志字段F(Flag)，规定为0x7E(符号0x表示它后面的字符是用十六进制表示的。十六进制的7E的二进制表示是01111110)，标志字段表示一个帧的开始。
首部中的地址字段A规定为0xFF(即11111111)。
首部中的控制字段C规定为0x03(即00000011)。
首部中的2字节的协议字段：
(1)当协议字段为0x0021时，PPP帧的信息字段就是IP数据报。
(2)当协议字段为0xC021时，PPP帧的信息字段就是PPP链路控制协议LCP的数据。
(3)当协议字段为0x8021时，PPP帧的信息字段就是网络层的控制数据。
(2) PPP帧的信息字段部分
信息字段的长度是可变的，不超过1500字节。
(3) PPP帧的尾部
尾部中的第一个字段(2个字节)是使用CRC的帧检验序列FCS。
尾部中的标志字段F(Flag)，规定为0x7E(符号0x表示它后面的字符是用十六进制表示的。十六进制的7E的二进制表示是01111110)，标志字段表示一个帧的结束。
注：标志字段就是PPP帧的定界符。连续两帧之间只需要用一个标志字段。如果连续出现两个标志字段，就表示这是一个空帧，应当丢弃。
透明传输的实现方式
当信息字段中出现和标志字段一样的比特(0x7E)组合时，就必须采取一些措施使这种形式上和标志字段一言的比特组合不出现在信息字段中。
(1) 字节填充------PPP使用异步传输
当PPP使用异步传输时，它把转移符定义为0x7D，并使用字节填充。
RFC1662规定了如下填充方法：
(1)把信息字段中出现的每一个0x7E字节转变为2字节序列(0x7D，0x5E)。
(2)若信息字段中出现一个0x7D的字节(即出现了和转义字符一样的比特组合)，则把转义字符0x7D转变为2字节序列(0x7D，0x5D)。
(3)若信息字段中出现ASCII码的控制字符(即数值小于0x20的字符)，则在该字符前面要加入一个0x7D字节，同时将该字符的编码加以改变。例如，出现0x03(在控制字符中是"传输结束"ETX)就要把它转变为2字节序列的(0x7D，0x31)。
由于在发送端进行了字节填充，因此在链路上传送的信息字节数就超过了原来的信息字节数。但接收端在接收到数据后再进行与发送端字节填充相反的变换，就可以正确地恢复出原来的信息。
(2) 零比特填充------PPP使用同步传输
当PPP使用同步传输时，使用零比特填充。
零比特填充的具体方法：
(1)在发送端先扫描整个信息字段(通常使用硬件实现，但也可以用软件实现，但是会慢一些)。
(2)只要发现有5个连续的1，则立即填入一个0。
(3)接收端在收到一个帧时，先找到标志字段F以确定帧的边界，接着再用硬件对其中的比特流进行扫描，每当发现5个连续1时，就把5个连续1后的一个0删除，以还原成原来的信息比特流。
因此通过这种零比特填充后的数据，就可以保证在信息字段中不会出现连续6个1。
网络层
IP协议
IP协议的工作机制
IP 协议提供了一种分层的、与硬件无关的寻址系统，它可以在复杂的路由式网络中传递数据所需的服务。
IP 协议可以将多个交换网络连接起来，在源地址和目的地址之间传送数据包。同时，它还提供数据重新组装功能，以适应不同网络对数据包大小的要求。
在一个路由式网络中，源地址主机向目标地址主机发送数据时，IP协议是如何将数据成功发送到目标主机上的呢？由于网络分同网段和不同网段两种情况，工作方式如下：
- 同网段：如果源地址主机和目标地址主机在同一网段，目标 IP 地址被 ARP 协议解析为 MAC 地址，然后根据 MAC 地址，源主机直接把数据包发给目标主机。
- 不同网段：如果源地址主机和目标地址主机在不同网段，数据包发送过程如下：
网关（一般为路由器）的 IP 地址被 ARP 协议解析为 MAC 地址。根据该 MAC 地址，源主机将数据包发送到网关。网关根据数据包中的网段 ID 寻找目标网络。如果找到，将数据包发送到目标网段；如果没找到，重复步骤（1）将数据包发送到上一级网关。数据包经过网关被发送到正确的网段中。目标IP地址被ARP协议解析为 MAC 地址。根据该 MAC 地址，数据包被发送给目标地址的主机。
IP数据报格式详解
在 TCP/IP 协议中，使用 IP 协议传输数据的包被称为 IP 数据包，每个数据包都包含 IP 协议规定的内容。IP 协议规定的这些内容被称为 IP 数据报文（IP Datagram）或者 IP 数据报。
IP 数据报文由首部（称为报头）和数据两部分组成。首部的前一部分是固定长度，共 20 字节，是所有 IP 数据报必须具有的。在首部的固定部分的后面是一些可选字段，其长度是可变的。
每个 IP 数据报都以一个 IP 报头开始。源计算机构造这个 IP 报头，而目的计算机利用 IP 报头中封装的信息处理数据。IP 报头中包含大量的信息，如源 IP 地址、目的 IP 地址、数据报长度、IP 版本号等。每个信息都被称为一个字段。
IP 数据报头字段如图所示。
IP 报头的最小长度为 20 字节，上图中每个字段的含义如下：
- 版本（version）：占 4 位，表示 IP 协议的版本。通信双方使用的 IP 协议版本必须一致。目前广泛使用的IP协议版本号为 4，即 IPv4。
- 首部长度（网际报头长度IHL）：占 4 位，可表示的最大十进制数值是 15。这个字段所表示数的单位是 32 位字长（1 个 32 位字长是 4 字节）。因此，当 IP 的首部长度为 1111 时（即十进制的 15），首部长度就达到 60 字节。当 IP 分组的首部长度不是 4 字节的整数倍时，必须利用最后的填充字段加以填充。数据部分永远在 4 字节的整数倍开始，这样在实现 IP 协议时较为方便。首部长度限制为 60 字节的缺点是，长度有时可能不够用，之所以限制长度为 60 字节，是希望用户尽量减少开销。最常用的首部长度就是 20 字节（即首部长度为 0101），这时不使用任何选项。
- 区分服务（tos）：也被称为服务类型，占 8 位，用来获得更好的服务。这个字段在旧标准中叫做服务类型，但实际上一直没有被使用过。1998 年 IETF 把这个字段改名为区分服务（Differentiated Services，DS）。只有在使用区分服务时，这个字段才起作用。
- 总长度（totlen）：首部和数据之和，单位为字节。总长度字段为 16 位，因此数据报的最大长度为 2^16-1=65535 字节。
- 标识（identification）：用来标识数据报，占 16 位。IP 协议在存储器中维持一个计数器。每产生一个数据报，计数器就加 1，并将此值赋给标识字段。当数据报的长度超过网络的 MTU，而必须分片时，这个标识字段的值就被复制到所有的数据报的标识字段中。具有相同的标识字段值的分片报文会被重组成原来的数据报。
- 标志（flag）：占 3 位。第一位未使用，其值为 0。第二位称为 DF（不分片），表示是否允许分片。取值为 0 时，表示允许分片；取值为 1 时，表示不允许分片。第三位称为 MF（更多分片），表示是否还有分片正在传输，设置为 0 时，表示没有更多分片需要发送，或数据报没有分片。
- 片偏移（offsetfrag）：占 13 位。当报文被分片后，该字段标记该分片在原报文中的相对位置。片偏移以 8 个字节为偏移单位。所以，除了最后一个分片，其他分片的偏移值都是 8 字节（64 位）的整数倍。
- 生存时间（TTL）：表示数据报在网络中的寿命，占 8 位。该字段由发出数据报的源主机设置。其目的是防止无法交付的数据报无限制地在网络中传输，从而消耗网络资源。路由器在转发数据报之前，先把 TTL 值减 1。若 TTL 值减少到 0，则丢弃这个数据报，不再转发。因此，TTL 指明数据报在网络中最多可经过多少个路由器。TTL 的最大数值为 255。若把 TTL 的初始值设为 1，则表示这个数据报只能在本局域网中传送。
- 协议：表示该数据报文所携带的数据所使用的协议类型，占 8 位。该字段可以方便目的主机的 IP 层知道按照什么协议来处理数据部分。不同的协议有专门不同的协议号。例如，TCP 的协议号为 6，UDP 的协议号为 17，ICMP 的协议号为 1。
- 首部检验和（checksum）：用于校验数据报的首部，占 16 位。数据报每经过一个路由器，首部的字段都可能发生变化（如TTL），所以需要重新校验。而数据部分不发生变化，所以不用重新生成校验值。
- 源地址：表示数据报的源 IP 地址，占 32 位。
- 目的地址：表示数据报的目的 IP 地址，占 32 位。该字段用于校验发送是否正确。
- 可选字段：该字段用于一些可选的报头设置，主要用于测试、调试和安全的目的。这些选项包括严格源路由（数据报必须经过指定的路由）、网际时间戳（经过每个路由器时的时间戳记录）和安全限制。
- 填充：由于可选字段中的长度不是固定的，使用若干个 0 填充该字段，可以保证整个报头的长度是 32 位的整数倍。
- 数据部分：表示传输层的数据，如保存 TCP、UDP、ICMP 或 IGMP 的数据。数据部分的长度不固定。
IP报文实例
传输层
ICMP协议
控制报文协议（Internet Control Message Protocol，ICMP）是 TCP/IP 协议族的一个子协议。ICMP 协议用于在 IP 主机和路由器之间传递控制消息，描述网络是否通畅、主机是否可达、路由器是否可用等网络状态。
由于 IP 协议简单，数据传输天然存在不可靠、无连接等特点，为了解决数据传输出现的问题，人们引入了 ICMP 协议。虽然 ICMP 协议的数据包并不传输用户数据，但是对于用户数据的传递起着重要的作用。
ICMP 协议作用
数据包在发送到目标主机的过程中，通常会经过一个或多个路由器。而数据包在通过这些路由进行传输时，可能会遇到各种问题，导致数据包无法发送到目标主机上。为了了解数据包在传输的过程中在哪个环节出现了问题，就需要用到 ICMP 协议。它可以跟踪消息，把问题反馈给源主机。
ICMP 报文结构
ICMP 报文一般为 8 个字节，包括类型、代码、校验和扩展内容字段。ICMP 报文基本结构如图所示。
其中，类型表示 ICMP 的消息类型，代码表示对类型的进一步说明，校验和表示对整个报文的报文信息的校验。
在 ICMP 报文中，如果类型和代码不同，ICMP 数据包报告的消息含义也会不同。常见的类型和代码的 ICMP 含义如表所示。
ICMP 类型、代码及含义
类型 代码 含义
0 0 回显应答（ping 应答）
3 0 网络不可达
3 1 主机不可达
3 2 协议不可达
3 3 端口不可达
3 4 需要进行分片，但设置不分片位
3 5 源站选路失败
3 6 目的网络未知
3 7 目的主机未知
3 9 目的网络被强制禁止
3 10 目的主机被强制禁止
3 11 由于服务类型 TOS，网络不可达
3 12 由于服务类型 TOS，主机不可达
3 13 由于过滤，通信被强制禁止
3 14 主机越权
3 15 优先中止失效
4 0 源端被关闭（基本流控制）
5 0 对网络重定向
5 1 对主机重定向
5 2 对服务类型和网络重定向
5 3 对服务类型和主机重定向
8 0 回显请求（ping 请求）
9 0 路由器通告
10 0 路由器请求
11 0 传输期间生存时间为 0
11 1 在数据报组装期间生存时间为 0
12 0 坏的 IP 首部
12 1 缺少必需的选项
13 0 时间戳请求
14 0 时间戳应答
17 0 地址掩码请求
18 0 地址掩码应答
ICMP报文实例
TCP协议
TCP协议的工作机制
传输控制协议（Transmission Control Protocol，TCP）是一种面向连接的、可靠的、基于字节流的传输层通信协议。在 TCP 协议中，通过三次握手建立连接。通信结束后，还需要断开连接。如果在发送数据包时，没有正确被发送到目的地时，将会重新发送数据包。
TCP 协议使用的是面向连接的方法进行通信的，其作用如下：
- 面向流的处理：TCP 以流的方式处理数据。换句话说，TCP 可以一个字节一个字节地接收数据，而不是一次接收一个预订格式的数据块。TCP 把接收到的数据组成长度不等的段，再传递到网际层。
- 重新排序：如果数据以错误的顺序到达目的地，TCP 模块能够对数据重新排序，来恢复原始数据。
- 流量控制：TCP 能够确保数据传输不会超过目的计算机接收数据的能力。
- 优先级与安全：为 TCP 连接设置可选的优先级和安全级别。
- 适当的关闭：以确保所有的数据被发送或接收以后，再进行关闭连接。
TCP 协议的数据包进行传输采用的是服务器端和客户端模式。发送 TCP 数据请求方为客户端，另一方则为服务器端。客户端要与服务器端进行通信，服务器端必须开启监听的端口，客户端才能通过端口连接到服务器，然后进行通信。
TCP报文格式解析
TCP 报文是 TCP 层传输的数据单元，也称为报文段。TCP 报文中每个字段如图所示。
上图中 TCP 报文中每个字段的含义如下：
- 源端口和目的端口字段：TCP源端口（Source Port）：源计算机上的应用程序的端口号，占 16 位。TCP目的端口（Destination Port）：目标计算机的应用程序端口号，占 16 位。
- 序列号字段：CP序列号（Sequence Number）：占 32 位。它表示本报文段所发送数据的第一个字节的编号。在 TCP 连接中，所传送的字节流的每一个字节都会按顺序编号。当SYN标记不为1时，这是当前数据分段第一个字母的序列号；如果SYN的值是1时，这个字段的值就是初始序列值（ISN），用于对序列号进行同步。这时，第一个字节的序列号比这个字段的值大1，也就是ISN加1。
- 确认号字段：TCP 确认号（Acknowledgment Number，ACK Number）：占 32 位。它表示接收方期望收到发送方下一个报文段的第一个字节数据的编号。其值是接收计算机即将接收到的下一个序列号，也就是下一个接收到的字节的序列号加1。
- 数据偏移字段：TCP 首部长度（Header Length）：数据偏移是指数据段中的"数据"部分起始处距离 TCP 数据段起始处的字节偏移量，占 4 位。其实这里的"数据偏移"也是在确定 TCP 数据段头部分的长度，告诉接收端的应用程序，数据从何处开始。
- 保留字段：保留（Reserved）：占 4 位。为 TCP 将来的发展预留空间，目前必须全部为 0。
- 标志位字段：
1.CWR（Congestion Window Reduce）：拥塞窗口减少标志，用来表明它接收到了设置 ECE 标志的 TCP 包。并且，发送方收到消息之后，通过减小发送窗口的大小来降低发送速率。
2.ECE（ECN Echo）：用来在 TCP 三次握手时表明一个 TCP 端是具备 ECN 功能的。在数据传输过程中，它也用来表明接收到的 TCP 包的 IP 头部的 ECN 被设置为 11，即网络线路拥堵。
3.URG（Urgent）：表示本报文段中发送的数据是否包含紧急数据。URG=1 时表示有紧急数据。当 URG=1 时，后面的紧急指针字段才有效。
4.ACK：表示前面的确认号字段是否有效。ACK=1 时表示有效。只有当 ACK=1 时，前面的确认号字段才有效。TCP 规定，连接建立后，ACK 必须为 1。
5.PSH（Push）：告诉对方收到该报文段后是否立即把数据推送给上层。如果值为 1，表示应当立即把数据提交给上层，而不是缓存起来。
6.RST：表示是否重置连接。如果 RST=1，说明 TCP 连接出现了严重错误（如主机崩溃），必须释放连接，然后再重新建立连接。
7.SYN：在建立连接时使用，用来同步序号。当 SYN=1，ACK=0 时，表示这是一个请求建立连接的报文段；当 SYN=1，ACK=1 时，表示对方同意建立连接。SYN=1 时，说明这是一个请求建立连接或同意建立连接的报文。只有在前两次握手中 SYN 才为 1。
8.FIN：标记数据是否发送完毕。如果 FIN=1，表示数据已经发送完成，可以释放连接。 - 窗口大小字段：窗口大小（Window Size）：占 16 位。它表示从 Ack Number 开始还可以接收多少字节的数据量，也表示当前接收端的接收窗口还有多少剩余空间。该字段可以用于 TCP 的流量控制。
- TCP 校验和字段：校验位（TCP Checksum）：占 16 位。它用于确认传输的数据是否有损坏。发送端基于数据内容校验生成一个数值，接收端根据接收的数据校验生成一个值。两个值必须相同，才能证明数据是有效的。如果两个值不同，则丢掉这个数据包。Checksum 是根据伪头 + TCP 头 + TCP 数据三部分进行计算的。
- 紧急指针字段：紧急指针（Urgent Pointer）：仅当前面的 URG 控制位为 1 时才有意义。它指出本数据段中为紧急数据的字节数，占 16 位。当所有紧急数据处理完后，TCP 就会告诉应用程序恢复到正常操作。即使当前窗口大小为 0，也是可以发送紧急数据的，因为紧急数据无须缓存。
- 可选项字段：选项（Option）：长度不定，但长度必须是 32bits 的整数倍。
TCP报文实例
UDP协议
UDP协议简介
用户数据报协议（User Datagram Protocol，UDP）是一种传输层协议。在 TCP/IP 网络中，它与 TCP 协议一样用于处理数据包，是一种无连接的协议。
TCP 协议在进行数据传输时，需要建立连接，并且每次传输的数据都需要进行确认。当不再进行传输数据时，还需要断开连接。这样做虽然安全，但是效率较低。而 UDP 协议正好避免了这些过程，它是一种没有复杂控制，提供面向无连接的通信服务协议。
UDP 协议具备以下特点：
- 没有各种连接：在传输数据前不需要建立连接，也避免了后续的断开连接。
- 不重新排序：对到达顺序混乱的数据包不进行重新排序。
- 没有确认：发送数据包无须等待对方确认。因此，使用 UDP 协议可以随时发送数据，但无法保证数据能否成功被目标主机接收。
UDP报文格式详解
相比 TCP 协议，UDP 协议的报文结构相对简单。
每个 UDP 报文分为 UDP 报头和 UDP 数据区两部分。报头由 4 个 16 位长（2 字节）字段组成，分别说明该报文的源端口、目的端口、报文长度和校验值。
UDP 报文格式如图所示。
UDP 报文中每个字段的含义如下：
- 源端口：这个字段占据 UDP 报文头的前 16 位，通常包含发送数据报的应用程序所使用的 UDP 端口。接收端的应用程序利用这个字段的值作为发送响应的目的地址。这个字段是可选的，所以发送端的应用程序不一定会把自己的端口号写入该字段中。如果不写入端口号，则把这个字段设置为 0。这样，接收端的应用程序就不能发送响应了。
- 目的端口：接收端计算机上 UDP 软件使用的端口，占据 16 位。
- 长度：该字段占据 16 位，表示 UDP 数据报长度，包含 UDP 报文头和 UDP 数据长度。因为 UDP 报文头长度是 8 个字节，所以这个值最小为 8。
- 校验值：该字段占据 16 位，可以检验数据在传输过程中是否被损坏。
UDP报文实例
应用层
HTTP协议
博客园 ranyonsue
HTTP之URL
HTTP使用统一资源标识符（Uniform Resource Identifiers, URI）来传输数据和建立连接。URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息
URL,全称是UniformResourceLocator, 中文叫统一资源定位符,是互联网上用来标识某一处资源的地址。以下面这个URL为例，介绍下普通URL的各部分组成：
http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name
从上面的URL可以看出，一个完整的URL包括以下几部分：
(1) 协议部分：该URL的协议部分为"http："，这代表网页使用的是HTTP协议。在Internet中可以使用多种协议，如HTTP，FTP等等本例中使用的是HTTP协议。在"HTTP"后面的"//“为分隔符。
(2) **域名部分：**该URL的域名部分为"www.aspxfans.com”。一个URL中，也可以使用IP地址作为域名使用。
(3) 端口部分：跟在域名后面的是端口，域名和端口之间使用":“作为分隔符。端口不是一个URL必须的部分，如果省略端口部分，将采用默认端口。
(4) 虚拟目录部分：从域名后的第一个”/“开始到最后一个”/“为止，是虚拟目录部分。虚拟目录也不是一个URL必须的部分。本例中的虚拟目录是”/news/"。
(5) 文件名部分：从域名后的最后一个"/“开始到”？“为止，是文件名部分，如果没有”?",则是从域名后的最后一个"/“开始到”#“为止，是文件部分，如果没有”？“和”#"，那么从域名后的最后一个"/“开始到结束，都是文件名部分。本例中的文件名是"index.asp”。文件名部分也不是一个URL必须的部分，如果省略该部分，则使用默认的文件名。
(6) 参数部分：从"？“开始到”#“为止之间的部分为参数部分，又称搜索部分、查询部分。本例中的参数部分为"boardID=5&ID=24618&page=1”。参数可以允许有多个参数，参数与参数之间用"&“作为分隔符。
(7) 锚部分：从”#“开始到最后，都是锚部分。本例中的锚部分是"name”。锚部分也不是一个URL必须的部分。
（原文：http://blog.csdn.net/ergouge/article/details/8185219 ）
HTTP之请求消息Request
客户端发送一个HTTP请求到服务器的请求消息包括以下格式：
请求行（request line）、请求头部（header）、空行和请求数据四个部分组成。
请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本。
(1) Get请求例子，使用Charles抓取的request：
GET /562f25980001b1b106000338.jpg HTTP/1.1
Host img.mukewang.com
User-Agent Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36
Accept image/webp,image/*,*/*;q=0.8
Referer http://www.imooc.com/
Accept-Encoding gzip, deflate, sdch
Accept-Language zh-CN,zh;q=0.8
第一部分：请求行，用来说明请求类型,要访问的资源以及所使用的HTTP版本.
GET说明请求类型为GET,[/562f25980001b1b106000338.jpg]为要访问的资源，该行的最后一部分说明使用的是HTTP1.1版本。
第二部分：请求头部，紧接着请求行（即第一行）之后的部分，用来说明服务器要使用的附加信息
从第二行起为请求头部，HOST将指出请求的目的地.User-Agent,服务器端和客户端脚本都能访问它,它是浏览器类型检测逻辑的重要基础.该信息由你的浏览器来定义,并且在每个请求中自动发送等等
第三部分：空行，请求头部后面的空行是必须的
即使第四部分的请求数据为空，也必须有空行。
第四部分：请求数据也叫主体，可以添加任意的其他数据。
这个例子的请求数据为空。
(2) POST请求例子，使用Charles抓取的request：
POST / HTTP1.1
Host:www.wrox.com
User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Content-Type:application/x-www-form-urlencoded
Content-Length:40
Connection: Keep-Alive
name=Professional%20Ajax&publisher=Wiley
第一部分：请求行，第一行明了是post请求，以及http1.1版本。
第二部分：请求头部，第二行至第六行。
第三部分：空行，第七行的空行。
第四部分：请求数据，第八行。
HTTP之响应消息Response
一般情况下，服务器接收并处理客户端发过来的请求后会返回一个HTTP的响应消息。
HTTP响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文。
第一部分：状态行，由HTTP协议版本号， 状态码， 状态消息 三部分组成。
第一行为状态行，（HTTP/1.1）表明HTTP版本为1.1版本，状态码为200，状态消息为（ok）
第二部分：消息报头，用来说明客户端要使用的一些附加信息
第二行和第三行为消息报头，Date:生成响应的日期和时间；Content-Type:指定了MIME类型的HTML(text/html),编码类型是UTF-8
第三部分：空行，消息报头后面的空行是必须的
第四部分：响应正文，服务器返回给客户端的文本信息。
空行后面的html部分为响应正文。
HTTP之状态码
状态代码有三位数字组成，第一个数字定义了响应的类别，共分五种类别:
1xx：指示信息–表示请求已接收，继续处理
2xx：成功–表示请求已被成功接收、理解、接受
3xx：重定向–要完成请求必须进行更进一步的操作
4xx：客户端错误–请求有语法错误或请求无法实现
5xx：服务器端错误–服务器未能实现合法的请求
常见状态码：
200 OK //客户端请求成功
400 Bad Request //客户端请求有语法错误，不能被服务器所理解
401 Unauthorized //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用
403 Forbidden //服务器收到请求，但是拒绝提供服务
404 Not Found //请求资源不存在，eg：输入了错误的URL
500 Internal Server Error //服务器发生不可预期的错误
503 Server Unavailable //服务器当前不能处理客户端的请求，一段时间后可能恢复正常
更多状态码http://www.runoob.com/http/http-status-codes.html
HTTP请求方法
根据HTTP标准，HTTP请求可以使用多种请求方法。
HTTP1.0定义了三种请求方法： GET, POST 和 HEAD方法。
HTTP1.1新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
GET 请求指定的页面信息，并返回实体主体。
HEAD 类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头
POST 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
PUT 从客户端向服务器传送的数据取代指定的文档的内容。
DELETE 请求服务器删除指定的页面。
CONNECT HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
OPTIONS 允许客户端查看服务器的性能。
TRACE 回显服务器收到的请求，主要用于测试或诊断。
HTTP工作原理
HTTP协议定义Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。
以下是 HTTP 请求/响应的步骤：
1、客户端连接到Web服务器
一个HTTP客户端，通常是浏览器，与Web服务器的HTTP端口（默认为80）建立一个TCP套接字连接。例如，http://www.oakcms.cn。
2、发送HTTP请求
通过TCP套接字，客户端向Web服务器发送一个文本的请求报文，一个请求报文由请求行、请求头部、空行和请求数据4部分组成。
3、服务器接受请求并返回HTTP响应
Web服务器解析请求，定位请求资源。服务器将资源复本写到TCP套接字，由客户端读取。一个响应由状态行、响应头部、空行和响应数据4部分组成。
4、释放连接TCP连接
若connection 模式为close，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接;若connection 模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求;
5、客户端浏览器解析HTML内容
客户端浏览器首先解析状态行，查看表明请求是否成功的状态代码。然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。客户端浏览器读取响应数据HTML，根据HTML的语法对其进行格式化，并在浏览器窗口中显示。
例如：在浏览器地址栏键入URL，按下回车之后会经历以下流程：
1、浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址;
2、解析出 IP 地址后，根据该 IP 地址和默认端口 80，和服务器建立TCP连接;
3、浏览器发出读取文件(URL 中域名后面部分对应的文件)的HTTP 请求，该请求报文作为 TCP 三次握手的第三个报文的数据发送给服务器;
4、服务器对浏览器请求作出响应，并把对应的 html 文本发送给浏览器;
5、释放 TCP连接;
6、浏览器将该 html 文本并显示内容;
FTP协议
iteye_5722 2016-11-13 14:28:46 713 收藏 7
简介
FTP的传输使用的是TCP数据包协议，TCP在建立连接前会先进行三次握手。不过FTP服务器比较麻烦一些，因为FTP服务器使用了两个连接，分别是命令通道与数据通道。因为是TCP数据包，所以这两个连接都需要经过三次握手。
根据数据连接的建立方式，FTP服务的数据传输可以分为主动模式（Active）和被动（Passive）模式。下面就这两种模式分别进行介绍。
主动模式
1、定义
主动模式是FTP服务器向FTP客户端传输数据的默认模式。当FTP客户端请求以主动模式传输数据时，由客户端向服务器端发送准备接受数据的IP地址和端口Y，该端口应该是大于1024的非特权端口。服务器端主动发起并建立到指定的IP地址和端口Y上的连接。由于Y端可以随机指定，导致这种方案要求客户端机器必须允许FTP服务器能够顺利地连接所有的端口，因此可能存在一定的安全隐患。
2、FTP服务器主动连接示意图
3、主动模式分析
步骤一：建立命令通道连接
如上图，客户端会随机取一个大于1024以上的端口（port AA）来与FTP服务器端的port 21实现连接，这个过程当然需要三次握手。实现连接后客户端便可以通过这个连接来对FTP服务器执行命令，查询文件名、下载、上传等等命令都是利用这个通道来执行的。
步骤二：通知FTP服务端使用Active且告诉连接的端口号
FTP服务器端的端口 21号主要用在命令的执行，但是当牵涉到数据流时，就不是使用这个连接了。客户端在需要数据的情况下，会告知服务器端要用什么方式连接，如果是主动模式连接，客户端会随机启用一个端口（port BB），且通过命令通道告知FTP服务器这两个信息，并等待FTP服务器端的连接。
步骤三：FTP服务端主动向客户端连接
FTP服务器由命令通道了解客户端的需求后，会主动由port 20向客户端port BB连接，这个连接当然也会经过三次握手。此时FTP的客户端与服务器端建立了两条连接，分别用在命令的执行和数据的传输。而默认FTP服务端使用主动连接端口就是port 20。这样就建立起"命令"与"数据传输"两个通道。
注意：
第1点：数据传输通道是在有数据传输的行为才会建立连接，并不是一开始连接到FTP服务器就立刻建立的数据通道。
第2点：命令通道的FTP默认为port 21。数据传输的FTP-DATA默认为port 20。
第3点：这两个端口的工作原理是不一样的，而且，两者的连接发起端是不一样的。首先port 21接受来自客户端的主动连接， port 20则是FTP服务器主动连接到客户端。
被动模式
1.定义
在被动模式下，客户端通过PASV命令获得服务器端IP地址和数据端口，然后向服务器端发起连接请求，从而建立数据连接。因此服务器端只是被动地监听在指定端口上的请求。
当连接某个FTP服务器失败时可以试着修改FTP客户端工具配置，改变传输模式，这样或许能够连接成功。
2、FTP被动连接示意图
3、被动模式分析
步骤一：客户端与服务器建立命令通道
同样需要建立命令通道，通过三次握手就可以建立起这个通道了。
步骤二：客户端发起PASV的连接要求
当使用数据通道命令时，客户端可通过命令通道发起PASV的被动式连接要求，并等待服务器的回应。
步骤三：FTP服务器启动数据端口，并通知客户端连接
如果你使用的FTP服务器是能够处理被动式连接的，此时FTP服务器会先启动一个监听端口。这个端口号码可以是随机的，也可以自定义某个范围的端口。然后FTP服务器会通过命令通道告知客户端已经启动的端口（port PASV），并等待客户端的连接。
步骤四：客户端随机取用大于1024的端口进行连接
最后你的客户端会随机取用一个大于1024端口来进行对FTP服务器port PASV连接。如果一切都顺利，那么FTP数据就可以通过port BB和port PASV来传送了。
注意：
第1点：被动模式FTP数据通道是由客户端向服务器端发起连接的。
4、被动模式抓包分析
通过ftp到ftp.ksu.edu.tw这个FTP服务器，我们抓一下包，下面是登录过程。
第一步：客户端发起命令通道的三次握手。
第二步：客户端发起PASV的连接请求。
第三步：服务器端启动数据端口，并告知客户端该端口号。
第四步：客户端发起数据通道的三次握手。
SSL/TLS 协议
原文地址：https://cshihong.github.io/2019/05/09/SSL%E5%8D%8F%E8%AE%AE%E8%AF%A6%E8%A7%A3/
SSL VPN可参考：SSL VPN技术原理
赏月斋 慎终如始 宁静致远 博客园
SSL简介
(1) SSL和TLS
SSL (Secure Sockets Layer）安全套接层。是由Netscape公司于1990年开发，用于保障Word Wide Web（WWW）通讯的安全。主要任务是提供私密性，信息完整性和身份认证。1994年改版为SSLv2,1995年改版为SSLv3.
TLS(Transport Layer Security）安全传输层协议,）用于在两个通信应用程序之间提供保密性和数据完整性。该标准协议是由IETF于1999年颁布，整体来说TLS非常类似SSLv3，只是对SSLv3做了些增加和修改。
(2) SSL协议介绍
SSL是一个不依赖于平台和运用程序的协议，位于TCP/IP协议与各种应用层协议之间，为数据通信提高安全支持。
(3) SSL加密知名协议
-
HTTP over SSL:
简写https，加密网页浏览是设计SSL的初衷，HTTP也是第一个使用SSL保障安全的应用层协议。
当Netscape在它的Navigator里面运用HTTP over SSL的时候，使用https://来标识HTTP over SSL，因此我常见的https的全称就是HTTP over SSL。后来HTTPS在RFC2818被标准化。HTTPS工作在443端口，而HTTP默认工作在80端口。 -
Email over SSL：
类似于HTTP over SSL，邮件协议例如：
SMTP，POP3、IMAP也能支持SSL。
SMTP over TLS的标准文档在RFC2487
POP3和IMAP over TLS的标准化文档在RFC2595.
SSL协议结构
SSL的体系结构中包含两个协议子层，其中底层是SSL记录协议层（SSL Record Protocol Layer）；高层是SSL握手协议层（SSL HandShake Protocol Layer）。
(1) SSL协议主要分为两层
SSL记录协议层的作用是为高层协议提供基本的安全服务。SSL记录协议针对HTTP协议进行了特别的设计，使得超文本的传输协议HTTP能够在SSL运行。纪录封装各种高层协议，具体实施压缩解压缩、加密解密、计算和校验MAC等与安全有关的操作。
SSL握手协议层包括SSL握手协议（SSL HandShake Protocol）、SSL密码参数修改协议（SSL Change Cipher Spec Protocol）和SSL告警协议（SSL Alert Protocol）。握手层的这些协议用于SSL管理信息的交换，允许应用协议传送数据之间相互验证，协商加密算法和生成密钥等。
SSL握手协议的作用是协调客户和服务器的状态，使双方能够达到状态的同步。
(2) 记录协议和握手协议
SSL记录协议：它建立在可靠的传输（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能。
SSL握手协议：它建立在SSL记录协议之上，用于在实际的数据传输开始之前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。
(3) SSL建立阶段与IPSec VPN类比的话，可以分为两个大阶段
- SSL建立的第一阶段：Handshake phase（握手阶段）：
- 协商加密算法
- 认证服务器
- 建立用于加密和MAC（Message Authentication Code）用的密钥
该阶段类似于IPSec VPN IKE的作用。
- SSL建立第二阶段：Secure data transfer phase（安全的数据传输阶段）：
在已经建立的SSL连接里安全的传输数据。
该阶段类似于IPSec VPN ESP的作用
SSL原理（SSL建立）握手协议总过程
在用SSL进行通信之前，首先要使用SSL的Handshake协议在通信两端握手，协商数据传输中要用到的相关安全参数（如加密算法、共享密钥、产生密钥所要的材料等），并对对端的身份进行验证。
SSL的建立过程总共有13个包，第一次建立至少需要9个包。
SSL建立第一阶段 ClientHello&ServerHello
客户端首先发送ClientHello消息到服务端，服务端收到ClientHello消息后，再发送ServerHello消息回应客户端。
握手第一步是客户端向服务端发送 Client Hello 消息，这个消息里包含了一个客户端生成的随机数 Random1、客户端支持的加密套件（Support Ciphers）和 SSL Version 等信息。
ClientHello中涉及到的消息具体如下：
- 客户端版本
- 按优先级列出客户端支持的协议版本，首选客户端希望支持的最新协议版本。
- 客户端随机数Random
- 会话ID（Session id）。如果客户端第一次连接到服务器，那么这个字段就会保持为空。上图中该字段为空，说明这是第一次连接到服务器。。如果该字段不为空，说明以前是与服务器有连接的，在此期间，服务器将使用Session ID映射对称密钥，并将Session ID存储在客户端浏览器中，为映射设置一个时间限。如果浏览器将来连接到同一台服务器（在时间到期之前），它将发送Session ID，服务器将对映射的Session ID进行验证，并使用以前用过的对称密钥来恢复Session，这种情况下不需要完全握手。也叫作SSL会话恢复。后面会有介绍。
- 加密套件。客户端会给服务器发送自己已经知道的密码套件列表，这是由客户按优先级排列的，但完全由服务器来决定发送与否。TLS中使用的密码套件有一种标准格式。上面的报文中，客户端发送了74套加密套件。服务端会从中选出一种来作为双方共同的加密套件。
- 压缩方法。为了减少带宽，可以进行压缩。但从成功攻击TLS的事例中来看，其中使用压缩时的攻击可以捕获到用HTTP头发送的参数，这个攻击可以劫持Cookie，这个漏洞我们称为CRIME。从TLS 1.3开始，协议就禁用了TLS压缩。
- 扩展包。其他参数（如服务器名称，填充，支持的签名算法等）可以作为扩展名使用。
这些是客户端问候的一部分，如果已收到客户端问候，接下来就是服务器的确认，服务器将发送服务器问候。
收到客户端问候之后服务器必须发送服务器问候信息，服务器会检查指定诸如TLS版本和算法的客户端问候的条件，如果服务器接受并支持所有条件，它将发送其证书以及其他详细信息，否则，服务器将发送握手失败消息。
如果接受，第二步是服务端向客户端发送 Server Hello 消息，这个消息会从 Client Hello 传过来的 Support Ciphers 里确定一份加密套件，这个套件决定了后续加密和生成摘要时具体使用哪些算法，另外还会生成一份随机数 Random2。注意，至此客户端和服务端都拥有了两个随机数（Random1+ Random2），这两个随机数会在后续生成对称秘钥时用到。
ServerHello中涉及到的具体参数：
- 服务器版本Version。服务器会选择客户端支持的最新版本。
- 服务器随机数Random。服务器和客户端都会生成32字节的随机数。用来创建加密密钥。
- 加密套件。服务器会从客户端发送的加密套件列表中选出一个加密套件。
- 会话ID（Session ID）。服务器将约定的Session参数存储在TLS缓存中，并生成与其对应的Session id。它与Server Hello一起发送到客户端。客户端可以写入约定的参数到此Session id，并给定到期时间。客户端将在Client Hello中包含此id。如果客户端在此到期时间之前再次连接到服务器，则服务器可以检查与Session id对应的缓存参数，并重用它们而无需完全握手。这非常有用，因为服务器和客户端都可以节省大量的计算成本。在涉及亚马逊和谷歌等流量巨大的应用程序时，这种方法存在缺点。每天都有数百万人连接到服务器，服务器必须使用Session密钥保留所有Session参数的TLS缓存。这是一个巨大的开销。为了解决这个问题，在扩展包里加入了Session Tickets, 在这里，客户端可以在client hello中指定它是否支持Session Ticket。然后，服务器将创建一个新的会话票证(Session Ticket)，并使用只有服务器知道的经过私钥加密的Session参数。它将存储在客户端上，因此所有Session数据仅存储在客户端计算机上，但Ticket仍然是安全的，因为该密钥只有服务器知道。此数据可以作为名为Session Ticket的扩展包含在Client Hello中。
- 压缩算法。如果支持，服务器将同意客户端的首选压缩方法。
- 扩展包。
这个阶段之后，客户端服务端知道了下列内容：
- SSL版本
- 密钥交换、信息验证和加密算法
- 压缩方法
- 有关密钥生成的两个随机数。
SSL建立第二阶段 服务器向客户端发送消息
服务器启动SSL握手第2阶段，是本阶段所有消息的唯一发送方，客户机是所有消息的唯一接收方。该阶段分为4步：
- 证书：服务器将数字证书和到根CA整个链发给客户端，使客户端能用服务器证书中的服务器公钥认证服务器。
- 服务器密钥交换（可选）：这里视密钥交换算法而定
- 证书请求：服务端可能会要求客户自身进行验证。
- 服务器握手完成：第二阶段的结束，第三阶段开始的信号
(1) Certificate消息（可选）—第一次建立必须要有证书。
一般情况下，除了会话恢复时不需要发送该消息，在SSL握手的全流程中，都需要包含该消息。消息包含一个X.509证书，证书中包含公钥，发给客户端用来验证签名或在密钥交换的时候给消息加密。
这一步是服务端将自己的证书下发给客户端，让客户端验证自己的身份，客户端验证通过后取出证书中的公钥。
(2) Server Key Exchange（可选）
根据之前在ClientHello消息中包含的CipherSuite信息，决定了密钥交换方式（例如RSA或者DH），因此在Server Key Exchange消息中便会包含完成密钥交换所需的一系列参数。
因为这里是DH算法，所以需要发送服务器使用的DH参数。RSA算法不需要这一步。
在Diffie-Hellman中，客户端无法自行计算预主密钥; 双方都有助于计算它，因此客户端需要从服务器获取Diffie-Hellman公钥。
由上图可知，此时密钥交换也由签名保护。
(3) Certificate Request（可选）------可以是单向的身份认证，也可以双向认证
这一步是可选的，如果在对安全性要求高的常见可能用到。服务器用来验证客户端。服务器端发出Certificate Request消息，要求客户端发他自己的证书过来进行验证。该消息中包含服务器端支持的证书类型（RSA、DSA、ECDSA等）和服务器端所信任的所有证书发行机构的CA列表，客户端会用这些信息来筛选证书。
(4) Server Hello Done
该消息表示服务器已经将所有信息发送完毕，接下来等待客户端的消息。
SSL建立第三阶段 客户端向服务器发送消息
客户端收到服务器发送的一系列消息并解析后，将本端相应的消息发送给服务器。
客户机启动SSL握手第3阶段，是本阶段所有消息的唯一发送方，服务器是所有消息的唯一接收方。该阶段分为3步：
- 证书（可选）：为了对服务器证明自身，客户要发送一个证书信息，这是可选的，在IIS中可以配置强制客户端证书认证。
- 客户机密钥交换（Pre-master-secret）：这里客户端将预备主密钥发送给服务端，注意这里会使用服务端的公钥进行加密。
- 证书验证（可选），对预备秘密和随机数进行签名，证明拥有（a）证书的公钥。
(1) Certificate（可选）
如果在第二阶段服务器端要求发送客户端证书，客户端便会在该阶段将自己的证书发送过去。服务器端在之前发送的Certificate Request消息中包含了服务器端所支持的证书类型和CA列表，因此客户端会在自己的证书中选择满足这两个条件的第一个证书发送过去。若客户端没有证书，则发送一个no_certificate警告。
(2) Client Key exchange
根据之前从服务器端收到的随机数，按照不同的密钥交换算法，算出一个pre-master，发送给服务器，服务器端收到pre-master算出main master。而客户端当然也能自己通过pre-master算出main master。如此以来双方就算出了对称密钥。
如果是RSA算法，会生成一个48字节的随机数，然后用server的公钥加密后再放入报文中。如果是DH算法，这是发送的就是客户端的DH参数，之后服务器和客户端根据DH算法，各自计算出相同的pre-master secret.
本消息在给服务器发送的过程中，使用了服务器的公钥加密。服务器用自己的私钥解密后才能得到pre-master key.（向服务器证明自己的确持有客户端证书私钥。）
(3) Certificate verify（可选）
只有在客户端发送了自己证书到服务器端，这个消息才需要发送。其中包含一个签名，对从第一条消息以来的所有握手消息的HMAC值（用master_secret）进行签名。
SSL建立第四阶段 完成握手协议，建立SSL连接
客户机启动SSL握手第4阶段，使服务器结束。该阶段分为4步，前2个消息来自客户机，后2个消息来自服务器。
建立起一个安全的连接，客户端发送一个Change Cipher Spec消息，并且把协商得到的CipherSuite拷贝到当前连接的状态之中。然后，客户端用新的算法、密钥参数发送一个Finished消息，这条消息可以检查密钥交换和认证过程是否已经成功。其中包括一个校验值，对客户端整个握手过程的消息进行校验。服务器同样发送Change Cipher Spec消息和Finished消息。握手过程完成，客户端和服务器可以交换应用层数据进行通信。
(1) ChangeCipherSpec
编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送（ChangeCipherSpec是一个独立的协议，体现在数据包中就是一个字节的数据，用于告知服务端，客户端已经切换到之前协商好的加密套件（Cipher Suite）的状态，准备使用之前协商好的加密套件加密数据并传输了）。
是一条事件消息。
(2) Clinet Finished
客户端握手结束通知, 表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验（使用HMAC算法计算收到和发送的所有握手消息的摘要，然后通过RFC5246中定义的一个伪函数PRF计算出结果，加密后发送。此数据是为了在正式传输应用数据之前对刚刚握手建立起来的加解密通道进行验证。）
(3) Server Finished
服务端握手结束通知。
使用私钥解密加密的Pre-master数据，基于之前(Client Hello 和 Server Hello)交换的两个明文随机数 random_C 和 random_S，计算得到协商密钥:enc_key=Fuc(random_C, random_S, Pre-Master)；计算之前所有接收信息的 hash 值，然后解密客户端发送的 encrypted_handshake_message，验证数据和密钥正确性；发送一个 ChangeCipherSpec（告知客户端已经切换到协商过的加密套件状态，准备使用加密套件和 Session Secret加密数据了）；服务端也会使用 Session Secret 加密一段 Finish 消息发送给客户端，以验证之前通过握手建立起来的加解密通道是否成功。
根据之前的握手信息，如果客户端和服务端都能对Finish信息进行正常加解密且消息正确的被验证，则说明握手通道已经建立成功，接下来，双方可以使用上面产生的Session Secret对数据进行加密传输了。
消息验证代码（HMAC）和TLS数据完整性
当服务器或客户端使用主密钥加密数据时，它还会计算明文数据的校验和（哈希值），这个校验和称为消息验证代码（MAC）。然后在发送之前将MAC包含在加密数据中。密钥用于从数据中生成MAC，以确保传输过程中攻击者无法从数据中生成相同的MAC，故而MAC被称为HMAC（哈希消息认证码）。另一方面，在接收到消息时，解密器将MAC与明文分开，然后用它的密钥计算明文的校验和，并将其与接收到的MAC进行比较，如果匹配，那我们就可以得出结论：数据在传输过程中没有被篡改。
几个重要的secret key
(1) PreMaster secret
PreMaster Secret是在客户端使用RSA或者Diffie-Hellman等加密算法生成的。它将用来跟服务端和客户端在Hello阶段产生的随机数结合在一起生成 Master Secret。PreMaster secret前两个字节是TLS的版本号，这是一个比较重要的用来核对握手数据的版本号。服务端需要对密文中解密出来对的PreMaster版本号跟之前Client Hello阶段的版本号进行对比，如果版本号变低，则说明被串改，则立即停止发送任何消息。
(2) Master secret
由于最后通过交换，客户端和服务端都会有Pre-master和随机数，这个随机数将作为后面产生Master secret的种子，结合PreMaster secret，客户端和服务端将计算出同样的Master secret。
为了保证信息的完整性和机密性，SSL需要有六个加密密钥：四个密钥和两个IV。为了信息的可信性，客户端需要一个密钥（HMAC），为了加密要有一个密钥，为了分组加密要一个IV，服务器也是如此。SSL需要的密钥是单向的，不同于那些在其他方向的密钥。如果在一个方向上有攻击，这种攻击在其他方向是没影响的。生成过程如下：
主密钥是由一系列的Hash值组成。
master_secret = PRF（pre_master_secret，“master secret”，ClientHello.random + ServerHello.random）[0…47];
根据要求，有4个密钥用于加密和验证每个消息的完整性，他们是：
客户端写入加密密钥：客户端用来加密数据，服务器用来解密数据。
服务器写入加密密钥：服务器用来加密数据，客户端用来解密数据。
客户端写入MAC密钥：客户端用来创建MAC，服务器用来验证MAC。
服务器写入MAC密钥：服务器用来创建MAC，客户端用来验证MAC。
SSL会话恢复：
会话恢复是指只要客户端和服务器已经通信过一次，它们就可以通过会话恢复的方式来跳过整个握手阶段二直接进行数据传输。
SSL采用会话恢复的方式来减少SSL握手过程中造成的巨大开销。
为了加快建立握手的速度，减少协议带来的性能降低和资源消耗(具体分析在后文)，TLS 协议有两类会话缓存机制：
会话标识 session ID: 由服务器端支持，协议中的标准字段，因此基本所有服务器都支持，服务器端保存会话ID以及协商的通信信息，Nginx 中1M 内存约可以保存4000个 session ID 机器相关信息，占用服务器资源较多;
会话记录 session ticket :t需要服务器和客户端都支持，属于一个扩展字段，支持范围约60%(无可靠统计与来源)，将协商的通信信息加密之后发送给客户端保存，密钥只有服务器知道，占用服务器资源很少。
二者对比，主要是保存协商信息的位置与方式不同，类似与 http 中的 session 与 cookie。二者都存在的情况下，(nginx 实现)优先使用 session_ticket。
会话恢复具体过程（Session ID机制）：
如果客户端和服务器之间曾经建立了连接，服务器会在握手成功后返回 session ID，并保存对应的通信参数在服务器中;
如果客户端再次需要和该服务器建立连接，则在 client_hello 中 session ID 中携带记录的信息，发送给服务器;
服务器根据收到的 session ID 检索缓存记录，如果没有检索到货缓存过期，则按照正常的握手过程进行;
如果检索到对应的缓存记录，则返回 change_cipher_spec 与 encrypted_handshake_message 信息，两个信息作用类似，encrypted_handshake_message 是到当前的通信参数与 master_secret的hash 值;
如果客户端能够验证通过服务器加密数据，则客户端同样发送 change_cipher_spec 与 encrypted_handshake_message 信息;
服务器验证数据通过，则握手建立成功，开始进行正常的加密数据通信。
会话恢复具体过程（ session ticket）：
如果客户端和服务器之间曾经建立了连接，服务器会在 new_session_ticket 数据中携带加密的 session_ticket 信息，客户端保存;
如果客户端再次需要和该服务器建立连接，则在 client_hello 中扩展字段 session_ticket 中携带加密信息，一起发送给服务器;
服务器解密 sesssion_ticket 数据，如果能够解密失败，则按照正常的握手过程进行;
如果解密成功，则返回 change_cipher_spec 与 encrypted_handshake_message 信息，两个信息作用与 session ID 中类似;
如果客户端能够验证通过服务器加密数据，则客户端同样发送 change_cipher_spec与encrypted_handshake_message 信息;
服务器验证数据通过，则握手建立成功，开始进行正常的加密数据通信。
SSL记录协议：
SSL记录协议主要用来实现对数据块的分块、加密解密、压缩与解压缩、完整性检查及封装各种高层协议。
每个SSL记录主要包含以下信息：
内容类型
协议版本号，目前有2.0和3.0版本
记录数据的长度
数据由载荷
散列算法计算消息认证代码
记录
将消息分割为多个片段；
对每个片段进行压缩
加上片段编号(防止重放攻击)计算消息验证码MAC值(保证数据完整性)，追加在压缩片段
对称密码加密；
加上数据类型、版本号、压缩后的长度组成的报头， 就是最终的报文数据；
应用数据传输：
在所有的握手阶段都完成之后，就可以开始传送应用数据了。应用数据在传输之前，首先要附加上MAC secret，然后再对这个数据包使用write encryption key进行加密。在服务端收到密文之后，使用Client write encryption key进行解密，客户端收到服务端的数据之后使用Server write encryption key进行解密，然后使用各自的write MAC key对数据的完整性包括是否被串改进行验证。
非对称加密算法
非对称加密算法需要两个密钥：公开密钥（publickey）和私有密钥（privatekey）。公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。
HTTPS协议中，前面的握手过程，服务器会将公钥发给客户端，客户端验证后生成一个密钥用公钥加密后发送给服务器，成功后建立通信。
通信过程客户端将请求数据用得到的公钥加密后，发给服务器，服务器用私钥解密。服务器用客户端给的密钥加密响应报文，发回给客户端，客户端用自己存的密钥解密。
忽略掉其他例如确定协议和版本号之类的环节，提炼出来的重要环节如下：
公私玥A用于非对称式加密，密钥B只用于普通的对称式加密。
简而言之就是这样，那么问题来了：你作为一个中间人，你没有服务器私钥A，是不能解密客户端发送的内容的，如果你没有客户端自己生成的密钥B，所以你也不能解密客户端发过去的内容的。
请注意：这两个私钥都是两端各自保存，而私钥A是只保存在服务器上，从不对外发送的。
结果就是，你收发的数据，他都能看到------------------但是他不能解密，看不懂。
这只是最普通的劫持HTTP的方式，HTTPS就是为了解决题主所说的这个中间人攻击而产生的，然而题主并没有去理解HTTPS的工作原理，而用HTTP的原始思路继续去思考HTTPS，所以题主这个方法是完全不可行的。
继续往下想，或许有人会觉得：
如果你自己签发一对非对称式公私钥C，还有密钥D，然后作为一个中间人。在一开始的通信环节，用公私钥C替代公私钥A，用密钥D替代密钥B。这样分发给对应的服务器和客户端，这样他们发给自己的信息，自己都能解密。然后自己再用真正的公钥A把解密后的信息重新加密发给服务器骗取响应报文，把响应报文用密钥B（前面客户端用公钥C加密后，被中间人用私钥C解密的刀）重新加密发回给客户端骗取新的请求报文。
这样岂不是可以瞒天过海？
那么在图中所示的验证环节，因为你的证书是自己签发的，所以证书跟指纹拿去去系统里可信颁发机构的证书那一对，肯定对不上。
例如我用Fiddler给自己签发了个证书，因为颁发者不在系统受信任证书颁发机构里，会直接报警：
如果你要假冒其他机构颁发证书，因为你没有颁发机构的密钥，那么你颁发的证书，结果指纹肯定没办法对上，还是一样会报警。
系统信任的颁发机构一般都是权威的大机构，当然你也可以自己导入自己信任的机构的证书，用来验证签名。
如果要实现HTTPS下的中间人攻击，你应该让自己的根证书进入系统里，让自己成为裁判。
这是HTTPS中间人攻击中最难也是最简单的一点------毕竟用户很好骗。
你可以这么做，或者跟上一张图证书中的第三第四行所示的那么做。
还有人就说了，我可以让用户回落到HTTP协议啊，中间人用HTTPS跟服务器通信，然后用HTTP跟客户端通信------要知道大部分用户在地址栏输入URL时，并没有指定协议的习惯，都是打www开头而不是打https://开头，能用HTTPS全是Web Server上80端口301 Location到HTTPS的功劳。
看起来似乎中间人充当了一个替换页面里HTTPS资源到HTTP的反向代理，好像可行性还是很高。
但是只要利用HSTS（HTTP Strict Transport Security，RFC6797）就可以解决这个问题。通过在HTTP Header中加入Strict-Transport-Security的声明，告诉浏览器在一定时间内必须通过HTTPS协议访问本域名下的资源。
这种情况下，只要用户曾经在安全网络环境下访问过一次某站，中间人在指定时间内也无法让其回落到HTTP。
原文地址：https://www.zhihu.com/question/22795329