文章目录
上一篇我们讲了Wireshark零基础入门到实战（一）基础篇
下面继续讲解协议篇
1 ARP协议的数据包分析
查看本地的arp缓存列表
arp -a
下面看arp请求与响应
arp响应的发送方和接收方互换，切MAC地址都是可用的。
2 Wireshark眼中的IP协议
用ICMP中的网络层的来分析IP协议
3 TCP与UDP协议详解
TCP三次握手
TCP四次挥手
UDP数据包
4 TCP中也有一个窗口
seq与ack的关系：
Ack的值表示下一个想要接收的序列号，ack可以对多个数据包累计确认，表示小于当前Ack的值均被确认。
Ack 的值等于请求包seq + len + 1
窗口大小表示客户端可接收的数据的大小：
当窗口大小为0时，就发送零窗口通知，告诉服务端自己不能接收数据了。
服务端怎么知道客户端的窗口啥时候才能使非零，当服务端接收到零窗口通知后，服务端发送保活数据包，客户端告知自己的窗口大小。服务端知道客户端窗口使非零时候就可以继续发送数据了。
5 TCP重传技术的研究
发送数据包之后，重传计时器就会启动，重传计时器时间到达之后依然没有收到ack，发送方就会重新发送数据。重传计时器的超时时间每次重传后悔翻倍。
发送方收到接收方连续相同的三个ack时，发送方悔立即重传。
假设发送方发送了1,2,3,4,5数据包，接收方接收了1,3,4,5数据包，2丢失了，怎么处理呢，可以重传2,3,4,5数据包，这样有点浪费，开启sack后，接收方可以告知发送方已经收到1,3,4,5数据包，只需要重传2就可以了。
6 用途广泛的ICMP协议
路由跟踪Tracert：用 IP 生存时间 (TTL) 字段和 ICMP 错误消息来确定从一个主机到网络上其他主机的路由。
首先，tracert送出一个TTL是1的IP 数据包到目的地，路径上的第一个路由器收到这个数据包，将TTL减1，TTL变为0，所以该路由器会将此数据包丢掉，并送回一个「ICMP time exceeded」消息（包括发IP包的源地址，IP包的所有内容及路由器的IP地址），tracert 收到这个消息后，便知道这个路由器存在于这个路径上，接着tracert 再送出另一个TTL是2 的数据包，发现第2 个路由器… tracert 每次将送出的数据包的TTL 加1来发现另一个路由器，这个重复的动作一直持续到某个数据包抵达目的地。由于tracert向不常见端口(30000以上)发送数据包，因此会收到「ICMP port unreachable」消息，故可判断到达目的地。
tracert的使用：
tracert 180.101.49.xxx
下面来分析下Itracert的报文
ttl的值从1逐渐增加，ttl减到0，路由器丢失包，并向我们发送路由器的ip等信息。直到ttl的值到14，icmp请求达到目标主机，这样就直到了这一路的路径。
7 容易被忽视的DHCP协议
DHCP(Dynamic Host Configuration Protocol)，动态主机配置协议，是一个应用层协议。当我们将客户主机ip地址设置为动态获取方式时，DHCP服务器就会根据DHCP协议给客户端分配IP，使得客户机能够利用这个IP上网。
DHCP的实现分为4步，分别是：
第一步：Client端在局域网内发起一个DHCP Discover包，目的是想发现能够给它提供IP的DHCP Server。
第二步：可用的DHCP Server接收到Discover包之后，通过发送DHCP Offer包给予Client端应答，意在告诉Client端它可以提供IP地址。
第三步：Client端接收到Offer包之后，发送DHCP Request包请求分配IP。
第四步：DHCP Server发送ACK数据包，确认信息。
DHCP只有当主机的ip地址过期或者重新启动系统的时候才会请求IP地址，可以通过重新启动网卡的方式启动DHCP服务
重新启动网卡命令
ipconfig /release
ipconfig /renew
下面我们抓包来分析，首先看到的是DHCP释放数据包，因为执行了ipconfig /release，所以ip释放了。然后是DHCP发现数据包，用于找DHCP服务器。详细字段信息如下：
DHCP服务器收到DHCP发现数据包，发送DHCP响应数据包
上面的过程是IP地址释放，重新请求IP地址的过程。如果是IP地址过期，就需要续租，续租只需要DHCP Request 和 DHCP Ack两个数据包就够了。
8 不可或缺的DNS协议
DNS用于解析域名对应的IP地址，客户端发送换一个DNS查询报文，收到一个DNS响应报文，便知道了域名对应的IP地址
DNS域名查询由两种方式，递归查询，迭代查询，如下图所示
递归查询，迭代查询是在本地域名服务器做的进行的，所以客户端只看到看DNS请求与响应。
9 每天都要接触的HTTP协议
http请求包含三个部分，三次握手建立连接，请求资源，四次挥手
10 为安全而生的HTTPS协议
这里就不详细讲解https的原理了，需要了解原理的，请参考
HTTPS(一) – 基础知识（密钥、对称加密、非对称加密、数字签名、数字证书
HTTPS(二) – SSL/TLS 工作原理和详细握手过程
10.1 https的工作原理
https的工作原理可以用下图总结
下图展示了一个完整的https请求的过程，结合抓包的内容，可以看的更清楚。
https的抓包如下：
10.2 第一步 client hello 消息
客户端通过发送 “client hello” 消息向服务器发起握手请求，该消息包含：
- 客户端所支持的 TLS 版本
- 随机数，包含两部分：时间戳（4-Bytes）和随机数（28-Bytes）
- session-id：用来表明一次会话，第一次建立没有。如果以前建立过，可以直接带过去。后面的扩展内容会详细讲到。
- 加密算法套装列表：客户端支持的加密-签名算法的列表，让服务器去选择。
- 压缩算法：似乎一般都不用
- 扩展字段：比如密码交换算法的参数、请求主机的名字等等
这里的随机数很重要。我们先记为Random1。
10.3 第二步 server hello 消息
包含
-
根据客户端支持的SSL/TLS协议版本，和自己的比较，确定使用的SSL/TLS协议版本
-
确定加密套件,压缩算法
-
产生了一个随机数Random2。注意，至此客户端和服务端都拥有了两个随机数（Random1+ Random2），这两个随机数会在后续生成对称秘钥时用到
10.4 第三步 Server => Client
这次传输包含三部分内容
- Certificate
- Server Key Exchange
- ServerHello Done
Certificate
这里主要就是把证书发送给Client。客户端拿到证书后就可以进行验证，同时获取到公钥，用于后面Random3的加密。
Server Key Exchange
这个消息是用来发送密钥交换算法相关参数和数据的。这里要提前提一下，就是根据密钥交换算法的不同，传递的参数也是不同的。
常用的密钥交换算法：RSA、DH（Diffie-Hellman）、ECDH（Ellipticcurve Diffie–Hellman）。
这里看到使用的ECDH。
ServerHello Done
这个就是Server来表示自己说完了。类似电影里别人拿对讲机说完话最后会有一个“完毕！”。
10.5 第四步 Client => Server
这次传输也包含三部分内容，也是做了一个优化
- Client Key Exchange
- Change Cipher Spec
- Encrypted Handshake Message
我们依次解读
Client Key Exchange
这个也是交换秘钥参数。
这里客户端会再生成一个随机数Random3。然后使用服务端传来的公钥进行加密得到密文PreMaster Key。服务端收到这个值后，使用私钥进行解密，得到Random3。这样客户端和服务端就都拥有了Random1、Random2和Random3。这样两边的秘钥就协商好了。后面数据传输就可以用协商好的秘钥进行加密和解密。
Change Cipher Spec
编码改变通知。这一步是客户端通知服务端后面再发送的消息都会使用前面协商出来的秘钥加密了，是一条事件消息。
Encrypted Handshake Message
这一步对应的是 Client Finish 消息，客户端将前面的握手消息生成摘要再用协商好的秘钥加密，这是客户端发出的第一条加密消息。服务端接收后会用秘钥解密，能解出来说明前面协商出来的秘钥是一致的。
10.6 第五步 Server => Client
包括三部分
- New Session Ticket
- Change Cipher Spec
- Encrypted Handshake Message
New Session Ticket
包含了一个加密通信所需要的信息，这些数据采用一个只有服务器知道的密钥进行加密。目标是消除服务器需要维护每个客户端的会话状态缓存的要求。这部分内容在后面的扩展部分会讲到
Change Cipher Spec
编码改变通知。这一步是服务端通知客户端后面再发送的消息都会使用加密，也是一条事件消息。
Encrypted Handshake Message
这一步对应的是 Server Finish 消息，服务端也会将握手过程的消息生成摘要再用秘钥加密，这是服务端发出的第一条加密消息。客户端接收后会用秘钥解密，能解出来说明协商的秘钥是一致的。
到这里双方SSL/TLS握手完成。
10.7 Https数据传输
接下来就真正的到了接口请求的阶段。TLS的Content-Type为Application Data。 传输的内容也是加密的。
10.8 Session Tickets
在TLS握手的最后一步中服务器将包含一个“New Session Ticket”信息，包含了一个加密通信所需要的信息，这些数据采用一个只有服务器知道的密钥进行加密。
这个Session Ticket由客户端存储，并可以在随后的一次会话中添加到 ClientHello消息的SessionTicket扩展中。因此，所有的会话信息只存储在客户端上，Session Ticket仍然是安全的，因为它是由只有服务器知道的密钥加密的。
Session Identifiers和Session Ticket机制通常分别被称为“会话缓存”和“无状态恢复”机制。无状态恢复的主要改进是消除服务器端的会话缓存，从而简化了部署，它要求客户在每一个新的会话开始时提供Session Ticket 直到Ticket过期。