1 实验内容
一、 ICMP报文分析
\1. 使用ping命令，在终端ping一个有效地址：
（1） 截图示意说明ICMP、IP数据包结构和含义
（2） 分别说明request和reply包
\2. ping一个无效地址：
（1） 截图示意说明ICMP、IP数据包结构和含义
（2） 分别说明request和reply包
二、访问任意http网站和https网站并抓包，分析从PC访问到结束访问网站的全数据流过程
\1. 分析DNS解析过程及请求回应报文结构，掌握DNS报文结构特征和DNS A记录
（1）nslookup –qt=a xxx.com 查询域名的A记录
截图示意说明DNS数据包结构和含义
分别说明request和response包
（2）nslookup查询一个无效地址：
截图示意说明DNS数据包结构和含义
分别说明request和response包
\2. 分析PC和网站建立连接和断开连接的过程(TCP三次握手、四次挥手、RST包抓包)
\3. 分析网络层IP协议工作原理及常见字段，判断是否存在分片重组
\4. 分析链路层ARP请求报文和响应报文，分析ARP协议工作原理及常见字段
\5. 分析HTTP请求报文和响应报文，分析HTTP工作原理及常见字段
\6. 分析HTTPS请求报文和响应报文，分析HTTPS工作原理及常见字段
2实验步骤与分析
2.1CMP报文分析
2.1.1使用ping命令，在终端ping 一个有效地址“github.com”
Request包
ICMP数据包结构
Type: 该字段有1个字节，表示特定类型的 ICMP 报文。一台主机向一个节点发送一个类型字段值为8的ICMP报文，如果途中没有异常（如果没有被路由丢弃，目标不回应ICMP或者传输失败），则目标返回类型字段值为0的ICMP报文，说明这台主机存在。
Code: 该字段有1个字节，进一步细分 ICMP 的类型。如上图所示，Type 的值为 8，Code 的值为0，表示回显请求。
Checksum: 该字段有2个字节，表示校验和。
Identifier: 该字段有2个字节，用于匹配 Request/Reply 的标识符。
Seq Num: 该字段有2个字节，用于匹配 Request/Reply 的序列号。
Data: 该字段有4个字节，数据载荷。
IP数据包结构
如上图所示，可以看到 IP 数据包的信息：
Version: 4，表示 IPv4。
Header Length: 报头长度20 bytes。
Time to live： 64， 生存时间。
Protocol: 1，表示 ICMP。
Source: 10.201.96.44，源 IP 地址。
Destination: 20.205.243.166，目的 IP 地址。
Reply包
ICMP数据包结构
Type: 该字段有1个字节，表示特定类型的 ICMP 报文。当ICMP数据包的类型字段为0时，表示该数据包是一个回显回答（Echo Reply）消息。
Code: 该字段有1个字节，进一步细分 ICMP 的类型。如上图所示，Type 的值为 0，Code 的值为0，表示回显回答。
Checksum: 该字段有2个字节，表示校验和。
Identifier: 该字段有2个字节，用于匹配 Request/Reply 的标识符。
Seq Num: 该字段有2个字节，用于匹配 Request/Reply 的序列号。
Data: 该字段有4个字节，数据载荷。
IP数据包结构
如上图所示，可以看到 IP 数据包的信息：
Version: 4，表示 IPv4。
Header Length: 报头长度20 bytes。
Time to live： 64， 生存时间。
Protocol: 1，表示 ICMP。
Source: 20.205.243.166，源 IP 地址。
Destination: 10.201.96.44，目的 IP 地址。
2.1.2使用ping命令，在终端ping 一个无效地址199.199.199.199
只能获取request包
ICMP数据包结构
Type: 该字段有1个字节，表示特定类型的 ICMP 报文。一台主机向一个节点发送一个类型字段值为8的ICMP报文。
Code: 该字段有1个字节，进一步细分 ICMP 的类型。如上图所示，Type 的值为 8，Code 的值为0，表示回显请求。
Checksum: 该字段有2个字节，表示校验和。
Identifier: 该字段有2个字节，用于匹配 Request/Reply 的标识符。
Seq Num: 该字段有2个字节，用于匹配 Request/Reply 的序列号。
Data: 该字段有4个字节，数据载荷。
IP数据包结构
如上图所示，可以看到 IP 数据包的信息：
Version: 4，表示 IPv4。
Header Length: 报头长度20 bytes。
Time to live： 64， 生存时间。
Protocol: 1，表示 ICMP。
Source: 10.201.96.44，源 IP 地址。
Destination: 199.199.199.199，目的 IP 地址。
2.2访问任意http网站和https网站并抓包，分析从PC访问到结束访问网站的全数据流过程
2.2.1. 分析DNS解析过程及请求回应报文结构，掌握DNS报文结构特征和DNS A记录
nslookup查询b站域名的A记录(这里使用百度的公共 DNS 服务器180.76.76.76)
获取DNS数据包
request包
数据包结构
UDP数据帧分析
格式如下：
SP:该字段占2个字节，源端口号为50241
DP: 该字段占2个字节，目的端口号为53
Length: 该字段占2个字节，长度，42bytes
Checksum: 该字段占2个字节，校验和
DNS报文分析
DNS报文结构为：
第一个是Transaction ID为标识字段,2字节,用于辨别DNS应答报文是哪个请求报文的响应.图中报文标识数为：0x0002。
第二个是Flags标志字段,如图所示：
QR(1比特)：查询/响应的标志位，1为响应，0为查询。
opcode(4比特)：定义查询或响应的类型(若为0则表示是标准的，若为1则是反向的，若为2则是服务器状态请求)。
AA(1比特)：授权回答的标志位。该位在响应报文中有效，1表示名字服务器是权限服务器
TC(1比特)：截断标志位。1表示响应已超过512字节并已被截断、
RD(1比特)：该位为1表示客户端希望得到递归回答
RA(1比特)：只能在响应报文中置为1，表示可以得到递归响应。
zero(3比特)：不说也知道都是0了，保留字段。
rcode(4比特)：返回码，表示响应的差错状态，通常为0和3，各取值含义如下：
0：表示无差错， 1：表示格式差错 ，2：表示问题在域名服务器上，3; 表示域参照问题
4: 表示查询类型不支持 ，5: 表示在管理上被禁止 ，6 – 15: 表示保留
接下来问题数、回答资源记录数、授权资源记录数、附加资源记录数：这四个字段都是两字节，分别对应下面的查询问题、回答、授权和附加信息部分的数量。在图中报文对应字段分别为1,0,0,0；
第七个是Queries为查询问题区域，其包含正在进行的查询信息。包含查询名(被查询主机名字的名字字段)、查询类型、查询类。图中报文查询名为：www.bilibili.com,查询类型为：A（IPv4地址）,查询类为：IN（Internet数据）。（观察报文发现图中报文仅有查询问题区域,故不做其他区域的分析）
Response包
数据包结构
UDP数据帧分析
格式如下：
SP:该字段占2个字节，源端口号为53
DP: 该字段占2个字节，目的端口号为50241
Length: 该字段占2个字节，长度，362bytes
Checksum: 该字段占2个字节，校验和
DNS报文分析
DNS报文结构为：
第一个是Transaction ID为标识字段,2字节,用于辨别DNS应答报文是哪个请求报文的响应.图中报文标识数为：0x0002。
第二个是Flags标志字段,如图所示：
QR(1比特)：查询/响应的标志位，1为响应，0为查询。
opcode(4比特)：定义查询或响应的类型(若为0则表示是标准的，若为1则是反向的，若为2则是服务器状态请求)。
AA(1比特)：授权回答的标志位。该位在响应报文中有效，1表示名字服务器是权限服务器
TC(1比特)：截断标志位。1表示响应已超过512字节并已被截断
RD(1比特)：该位为1表示客户端希望得到递归回答
RA(1比特)：只能在响应报文中置为1，表示可以得到递归响应。
zero(3比特)：不说也知道都是0了，保留字段。
rcode(4比特)：返回码，表示响应的差错状态，通常为0和3，各取值含义如下：
0：表示无差错， 1：表示格式差错 ，2：表示问题在域名服务器上，3; 表示域参照问题
4: 表示查询类型不支持 ，5: 表示在管理上被禁止 ，6 – 15: 表示保留
接下来问题数、回答资源记录数、授权资源记录数、附加资源记录数：这四个字段都是两字节，分别对应下面的查询问题、回答、授权和附加信息部分的数量。在图中报文对应字段分别为1,20,0,0；
第七个是Queries为询问题区域，其包含正在进行的查询信息。包含查询名(被查询主机名字的名字字段)、查询类型、查询类。图中报文查询名为：www.bilibili.com,查询类型为：A（IPv4地址）,查询类为：IN（Internet数据）。第八个是Answers为回答区域，包含了查询的域名，指定了回答的资源记录类型，”A”记录表示IPv4地址，以及生存时间（TTL）2min9s，指定了回答的资源记录可以被缓存的时间，解析得的ip地址等
nslookup查询一个无效地址www.oppp.com
request包
UDP数据帧分析
格式如下：
SP:该字段占2个字节，源端口号为60222
DP: 该字段占2个字节，目的端口号为53
Length: 该字段占2个字节，长度，38bytes
Checksum: 该字段占2个字节，校验和
DNS报文分析
DNS报文结构为：
第一个是Transaction ID为标识字段,2字节,用于辨别DNS应答报文是哪个请求报文的响应.图中报文标识数为：0x0002。
第二个是Flags标志字段,如图所示：
QR(1比特)：查询/响应的标志位，1为响应，0为查询。
opcode(4比特)：定义查询或响应的类型(若为0则表示是标准的，若为1则是反向的，若为2则是服务器状态请求)。
AA(1比特)：授权回答的标志位。该位在响应报文中有效，1表示名字服务器是权限服务器(关于权限服务器以后再讨论)
TC(1比特)：截断标志位。1表示响应已超过512字节并已被截断
RD(1比特)：该位为1表示客户端希望得到递归回答
RA(1比特)：只能在响应报文中置为1，表示可以得到递归响应。
zero(3比特)：不说也知道都是0了，保留字段。
rcode(4比特)：返回码，表示响应的差错状态，通常为0和3，各取值含义如下：
0：表示无差错， 1：表示格式差错 ，2：表示问题在域名服务器上，3; 表示域参照问题
4: 表示查询类型不支持 ，5: 表示在管理上被禁止 ，6 – 15: 表示保留
接下来问题数、回答资源记录数、授权资源记录数、附加资源记录数：这四个字段都是两字节，分别对应下面的查询问题、回答、授权和附加信息部分的数量。在图中报文对应字段分别为1,0,0,0；
第七个是Queries为查询问题区域，其包含正在进行的查询信息。包含查询名(被查询主机名字的名字字段)、查询类型、查询类。图中报文查询名为：www.oppp.com,查询类型为：A（IPv4地址）,查询类为：IN（Internet数据）。
Response包
UDP数据帧分析
格式如下：
SP:该字段占2个字节，源端口号为53
DP: 该字段占2个字节，目的端口号为60222
Length: 该字段占2个字节，长度，88bytes
Checksum: 该字段占2个字节，校验和
DNS报文分析
DNS报文结构为：
第一个是Transaction ID为标识字段,2字节,用于辨别DNS应答报文是哪个请求报文的响应.图中报文标识数为：0x0002。
第二个是Flags标志字段,如图所示：
QR(1比特)：查询/响应的标志位，1为响应，0为查询。
opcode(4比特)：定义查询或响应的类型(若为0则表示是标准的，若为1则是反向的，若为2则是服务器状态请求)。
AA(1比特)：授权回答的标志位。该位在响应报文中有效，1表示名字服务器是权限服务器
TC(1比特)：截断标志位。1表示响应已超过512字节并已被截断
RD(1比特)：该位为1表示客户端希望得到递归回答
RA(1比特)：只能在响应报文中置为1，表示可以得到递归响应。
zero(3比特)：不说也知道都是0了，保留字段。
rcode(4比特)：返回码，表示响应的差错状态，通常为0和3，各取值含义如下：
0：表示无差错， 1：表示格式差错 ，2：表示问题在域名服务器上，3; 表示域参照问题
4: 表示查询类型不支持 ，5: 表示在管理上被禁止 ，6 – 15: 表示保留
接下来问题数、回答资源记录数、授权资源记录数、附加资源记录数：这四个字段都是两字节，分别对应下面的查询问题、回答、授权和附加信息部分的数量。在图中报文对应字段分别为1,0,1,0；
第七个是Queries为查询问题区域，其包含正在进行的查询信息。包含查询名(被查询主机名字的名字字段)、查询类型、查询类。图中报文查询名为：www.oppp.com,查询类型为：A（IPv4地址）,查询类为：IN（Internet数据）。
第八个是Authority为授权区域，包含了查询的域名，指定了授权的资源记录类型，标识为”SOA”，表示这是一个Start of Authority资源记录。以及生存时间（TTL）10min等
2.2.2分析PC和网站建立连接和断开连接的过程(TCP三次握手、四次挥手、RST包抓包)
打开一个新的浏览器输入www.bilibili.com 然后在后台开启wireshark的抓包功能
通过cmd窗口下的ipconfig查看电脑本地IP地址为10.201.96.44
查询一下b站IP地址发现是171.214.10.140
筛选条件ip.src == 171.214.10.140 or ip.dst == 171.214.10.140查询
前面的三个报文就是TCP的三次握手过程：SYN包，SYN ACK包，ACK报文。
方框处也就是“三次握手的结果。
第一次的标志是“[SYN]”,序列号seq为0， 代表客户端请求建立连接
第二次的标志是“[SYN, ACK]”,序列号Seq为0，Ack值为客户端发送过来的Seq加1，也就是1，表示服务器可以正常接收客户端数据包。
第三次的标志是“[ACK]”,客户端表示可以正常接收服务器数据包，这是为了保证可以全双工通讯，接下来就可以正常发送数据。
展开看详情：
第一次握手的报文如下：这是客户端发起给服务器的报文，用于请求建立连接。
可以看到TCP报文里有一个Flags位：
当Syn位标记为1的时候，表示这个报文是一个请求链接的报文；
自己的序号（sequence number）：0
第二次握手的报文如下：这是服务器回复给客户端的报文，用于确认并同意连接请求。
可以看到TCP报文里的Flags位：
Syn位也标记为1，表示这个报文是一个同意建立链接的报文；
ACK位也标记为1，表示是一个对上一个报文的确认报文；
Sequence number：自己的序号；
acknowledgment number：表示对上一个请求报文的确认号，所以是在上一个报文的序号+1
第三次握手：是客户端发给服务器的，是对上一个同意连接请求的确认。
Flags里的ACK位标记为1，表示是一个对上一个报文的确认报文；
Sequence number：自己的序号，在上一个报文的基础上+1；
acknowledgment number：表示对上一个请求报文的确认号，在上一个报文序号的基础上+1.
至此，三次握手完成！接下来就开始发送HTTP的请求了。
TCP协议的四次挥手过程
当数据传输结束了，客户端和服务器之间就开始断开连接了。断开连接需要经历四次挥手，具体过程如下：
同样，我们用wireshark工具来进行详细过程的报文的分析（这里b站的四次挥手一直找不到，所以换成了www.51cto.com）
四次挥手标志分别为：
“[FIN, ACK]”
“[ACK]”
“[FIN, ACK]”
“[ACK]”
我们同样展开看下详细的报文内容：
第一次挥手：当数据传输首先结束的端（比如客户端），会率先发起结束断开连接的请求：
Flags位的 Fin位标记为1，说明这是个一个断开连接的请求的报文。
Sequence number为3772
这时候我们发送这个请求的端已经停止发送数据了！但是还可以接受数据。
第二次挥手：对上一个断开连接请求的报文进行确认。并同时，停止接受数据。
所以，我们能看到这个报文的ACK位标记为1，并且acknowledgment number是对上一个报文的序号+1，即3772+1=3773，表示对上一个报文的确认。
第三次挥手：服务器端也结束数据发送了，所以也会发起一个断开连接的请求。
这是个服务器发起FIN报文，请求断开连接，同时，服务器也会停止发送数据。
第四次挥手：是客户端对服务器断开连接请求的进行确认。
所以这个flags位是ACK位标记为1。此时，客户端也停止接受数据了。
至此，服务器和客户端都停止发送和接受数据了！四次挥手就完成了。
2.2.3分析网络层IP协议工作原理及常见字段，判断是否存在分片重组
IP数据报
TCP中的字段分析，其ip版本号和头部长度字段如下：
版本：占4位，表示该IP数据报使用的IP协议版本。代表IPv4
首部长度：占4位，固定长度20字节。
总长度：数据报的长度，占16位=首部+数据，单位为字节，因此理论上数据报的最大长度为2^16-1=65535字节，总长度不能超过最大传送单元MTU。
上层协议标识：占用8位二进制位，IP协议可以承载各种上层协议，目标端根据协议标识就可以把收到的IP数据报送到TCP或UDP等处理此报文
标志：占3位。只有前2位有意义。最低位：MF MF=1：后边还有分片 MF=0：表示最后一个分片。
片偏移：13位。较长数组在分片后某片在原分组中的相对位置。
生存时间：TTL。数据报在网络汇总可通过路由器的最大值。
协议：表示数据报使用的哪个协议。的上层协议了。
首部检验和：首部检验IP和占16位，在IP数据报首部中进行容错检验。
源地址：源地址占32位，指明源主机的IP地址10.201.96.44。在IP数据报从源主机发送到目的主机的时间内，这个字段必须保持不变。
目的地址：目的地址占32位，指明目的主机的IP地址203.107.44.140，在IP数据报从源主机发送到目的的主机的时间内。
接下来开始判断是否存在分片重组
将flags展开发现DF位=1，MF位=0，说明不存在分片重组！
2.2.4分析链路层ARP请求报文和响应报文，分析ARP协议工作原理及常见字段
ARP协议工作原理分析
ARP整个完整交互过程仅需要两个包，一问一答即可搞定！ 一个是 ARP 请求过程，一个是 ARP 应答过程。
当主机PC1想要给主机PC2发送数据时，主机PC1会首先在自己的本地ARP缓存表中检查与主机PC2相匹配的MAC地址。如果主机PC1在自己的缓存表中没找到主机PC2的相关条目，那么它就要想办法获取主机PC2的MAC地址。这就需要将ARP的请求帧广播到本地网络上的所有主机中。
过滤ARP协议的数据包
显示过滤器中输入：arp，过滤ARP协议的数据包。
第一个包是ARP请求包，第三个包是ARP响应包。
ARP请求包
ARP后面的括号里是 request，说明这是个请求包
ARP请求的头部信息。按照顺序依次为硬件类型、协议类型、硬件地址长度、协议长度、操作码（该值为1，表示这是一个ARP请求包）、发送方的MAC和IP地址，以及接收方的IP地址
ARP响应包
其实ARP响应的数据包和ARP请求的数据包很相像。不同之处表现在以下几点：首先，用于响应的数据包的操作码（Opcode）现在是2，表明这是一个用于响应的数据包；其次，发送方的MAC地址和IP地址变成了目标MAC地址和IP地址；最后，响应数据包中的内容都是可用的，也就是说我们已经获取了10.201.127.254主机的MAC地址，即80:05:88:59:bb:9d，那么接下来就可以正常通信了。
2.2.5分析HTTP请求报文和响应报文，分析HTTP工作原理及常见字段
HTTP 是一个无状态的协议。无状态 是指客户端 （Web 浏览器）和 服务器之间不 需要建立持久的链接。这 意味着当一个客户端向服务器端发出请求，然后Web 服务器返回响应 ”*”(response) ，连接就被关闭了，在服务器端不保留连接的有关信息 .HTTP 遵 循请求 (Request)/ 应答 (Response) 模型。客户端（Web 浏览器） 向Web 服务器发送请求， Web 服务器处理请求并返回适当的应答。所有 HTTP 连 接都被构造成一套请求和应答。在 该过程中 要经过4 个 阶段，包括建立连接、发送请求信息、发送 响应信息和关闭连接，如下图所示:
HTTP工作原理分析
HTTP 请求报文
HTTP 请求报文由请求行、请求头部、空行 和 请求包体 4 个部分组成，如下图所示：
HTTP 工作原理
HTTP 协议采用请求/响应模型。客户端向服务器发送一个请求报文，服务器以一个状态作为响应。
以下是 HTTP 请求/响应的步骤：
客户端连接到web服务器：HTTP 客户端与web服务器建立一个 TCP 连接;
客户端向服务器发起 HTTP 请求：通过已建立的TCP 连接，客户端向服务器发送一个请求报文;
服务器接收 HTTP 请求并返回 HTTP 响应：服务器解析请求，定位请求资源，服务器将资源副本写到 TCP 连接，由客户端读取;
释放 TCP 连接：若connection 模式为close，则服务器主动关闭TCP 连接，客户端被动关闭连接，释放TCP 连接;若connection 模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求;
客户端浏览器解析HTML内容：客户端将服务器响应的 html 文本解析并显示;
例如：在浏览器地址栏键入URL，按下回车之后会经历以下流程：
1、浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址;
2、解析出 IP 地址后，根据该 IP 地址和默认端口 80，和服务器建立 TCP 连接;
3、浏览器发出读取文件(URL 中域名后面部分对应的文件)的HTTP 请求，该请求报文作为 TCP 三次握手的第三个报文的数据发送给服务器;
4、服务器对浏览器请求作出响应，并把对应的 html 文本发送给浏览器;
5、释放 TCP 连接;
6、浏览器将该 html 文本并显示内容;
下面 详细介绍上图中描述的HTTP 工作流程，如下：
客户端 通过TCP 三次握手与服务器建立连接。
TCP 建立连接成功后，向 服务器发送HTTP 请求。
服务器 接收客户端的HTTP 请求后，将返回应答，并向客户端发送数据
客户端 通过TCP 四次断开，与服务器断开 TCP 连接。
输入http://bbs.whu.edu.cn/登录珞珈山水
筛选抓取http包
请求数据包
GET/wForum/frames.php?target=../bbsnew.php HTTP/1.1\r\n
请求方法 GET 表示一个读取数据请求，/wForum/frames.php?target=../bbsnew.php表示URL 的路径，URL 总是以/开头，HTTP/1.1 指示采用的 HTTP 协议版本是 1.1;请求域名如下所示：
User-Agent：产生请求的浏览器类型;
Accept：客户端可识别的响应内容类型列表;星号 “ * ” 用于按范围将类型分组，用 “ / ” 指示可接受全部类型，用“ type/* ”指示可接受 type 类型的所有子类型;
Accept-Language：客户端可接受的自然语言;
Accept-Encoding：客户端可接受的编码压缩格式;
Accept-Charset：可接受的应答的字符集;
响应报文如下
Request version：HTTP/1.1
server：ngnix 服务器类型
Status code：200，响应报文状态码200表示”OK”，当客户端发送请求后，服务器成功处理请求并返回所请求的资源时，会返回200状态码。
Connection：Keep-Alive表示客户端希望与服务器建立持久连接。持久连接意味着在单个TCP连接上可以发送多个HTTP请求和响应
定位到登陆认证的这条POST请求可以看到用户名和密码都是明文传输。假如有中间人嗅探的话，用户名密码就泄露了。
可以发现Id=kaede,password=1234
2.2.6分析HTTPS请求报文和响应报文，分析HTTPS工作原理及常见字段
HTTPS (Secure Hypertext Transfer Protocol)安全超文本传输协议，是一个安全通信通道，它基于HTTP开发用于在客户计算机和服务器之间交换信息。它使用安全套接字层(SSL)进行信息交换，简单来说它是HTTP的安全版,是使用TLS/SSL加密的HTTP协议。
SSL (Secure Sockets Layer）安全套接层。是由Netscape公司于1990年开发，用于保障Word Wide Web（WWW）通讯的安全。主要任务是提供私密性，信息完整性和身份认证。1994年改版为SSLv2,1995年改版为SSLv3。
TLS(Transport Layer Security）安全传输层协议。用于在两个通信应用程序之间提供保密性和数据完整性。该标准协议是由IETF于1999年颁布，整体来说TLS非常类似SSLv3，只是对SSLv3做了些增加和修改。
TLS/SSL全称安全传输层协议Transport Layer Security, 是介于TCP和HTTP之间的一层安全协议，不影响原有的TCP协议和HTTP协议，所以使用HTTPS基本上不需要对HTTP页面进行太多的改造。
以豆瓣https://www.douban.com/为例，网站使用HTTPS，使用Wireshark抓取登陆过程中的报文。
SSL建立第一阶段：Client Hello，Server Hello
客户端首先发送Client Hello消息到服务端，服务端收到ClientHello消息后，再发送ServerHello消息回应客户端。
Client Hello
握手第一步是客户端向服务端发送 Client Hello 消息，这个消息里包含了一个客户端生成的随机数Random1、客户端支持的加密套件（Support Ciphers）和 SSL Version 等信息。通过 Wireshark 抓包，我们可以看到如下信息：
Version：客户端版本：按优先级列出客户端支持的协议版本，首选客户端希望支持的最新协议版本。
客户端随机数Random：随机数用于后续密钥的生成
会话ID（Session id）
如果客户端第一次连接到服务器，那么这个字段就会保持为空。
如果该字段不为空，说明以前是与服务器有连接的，在此期间，服务器将使用Session ID映射对称密钥，并将Session ID存储在客户端浏览器中，为映射设置一个时间限。如果浏览器将来连接到同一台服务器（在时间到期之前），它将发送Session ID，服务器将对映射的Session ID进行验证，并使用以前用过的对称密钥来恢复Session，这种情况下不需要完全握手。也叫作SSL会话恢复
加密套件（cipher suites）：客户端会给服务器发送自己已经知道的密码套件列表，这是由客户按优先级排列的，但完全由服务器来决定发送与否。TLS中使用的密码套件有一种标准格式。上面的报文中，客户端发送了17套加密套件。服务端会从中选出一种来作为双方共同的加密套件。
压缩方法（compress methods）：为了减少带宽，可以进行压缩。但从成功攻击TLS的事例中来看，其中使用压缩时的攻击可以捕获到用HTTP头发送的参数，这个攻击可以劫持Cookie，这个漏洞我们称为CRIME。从TLS 1.3开始，协议就禁用了TLS压缩。
Server Hello
服务端向客户端发送 Server Hello 消息，这个消息会从 Client Hello 传过来的 Support Ciphers 里确定一份加密套件，这个套件决定了后续加密和生成摘要时具体使用哪些算法，另外还会生成一份随机数 Random2。注意，至此客户端和服务端都拥有了两个随机数（Random1+ Random2），这两个随机数会在后续生成对称秘钥时用到。
1.服务器版本Version
服务器会选择客户端支持的最新版本。
2.服务器随机数Random
服务器和客户端都会生成32字节的随机数。用来创建加密密钥。
3.加密套件
服务器会从客户端发送的加密套件列表中选出一个加密套件。
4.会话ID（Session ID）
服务器将约定的Session参数存储在TLS缓存中，并生成与其对应的Session id。它与Server Hello一起发送到客户端。客户端可以写入约定的参数到此Session id，并给定到期时间。客户端将在Client Hello中包含此id。如果客户端在此到期时间之前再次连接到服务器，则服务器可以检查与Session id对应的缓存参数，并重用它们而无需完全握手。这非常有用，因为服务器和客户端都可以节省大量的计算成本。
5.压缩算法
如果支持，服务器将同意客户端的首选压缩方法。
6扩展包
在第一个阶段完成之后，客户端服务端知道了下列内容：
SSL版本
密钥交换、信息验证和加密算法
压缩方法
有关密钥生成的两个随机数。
SSL建立第二阶段：Certificate，Server Hello Done
服务器启动SSL握手第2阶段，是本阶段所有消息的唯一发送方，客户机是所有消息的唯一接收方。该阶段分为4步：
证书（可选）：服务器将数字证书和到根CA整个链发给客户端，使客户端能用服务器证书中的服务器公钥认证服务器。
服务器密钥交换（可选）：这里视密钥交换算法而定
证书请求（可选）：服务端可能会要求客户自身进行验证。
服务器握手完成：第二阶段的结束，第三阶段开始的信号
Certificate（可选）第一次建立必须要有证书
服务端将自己的证书下发给客户端，让客户端验证自己的身份，客户端验证通过后取出证书中的公钥。
Server Key Exchange（可选）
根据之前在ClientHello消息中包含的CipherSuite信息，决定了密钥交换方式（例如RSA或者DH），因此在Server Key Exchange消息中便会包含完成密钥交换所需的一系列参数。省略报文。
Certificate Request（可选）——可以是单向的身份认证，也可以双向认证
这一步是可选的，如果在对安全性要求高的常见可能用到。服务器用来验证客户端。服务器端发出Certificate Request消息，要求客户端发他自己的证书过来进行验证。该消息中包含服务器端支持的证书类型（RSA、DSA、ECDSA等）和服务器端所信任的所有证书发行机构的CA列表，客户端会用这些信息来筛选证书。省略报文。
Server Hello Done
Server Hello Done 通知客户端 Server Hello 过程结束，表示服务器已经将所有信息发送完毕，接下来等待客户端的消息。
SSL建立第三阶段：Client Key Exchange
客户端收到服务器发送的一系列消息并解析后，将本端相应的消息发送给服务器。
Client Key Exchange
上面客户端根据服务器传来的公钥生成了 PreMaster Key，Client Key Exchange 就是将这个 key 传给服务端，服务端再用自己的私钥解出这个 PreMaster Key 得到客户端生成的 Random3。至此，客户端和服务端都拥有 Random1 + Random2 + Random3，两边再根据同样的算法就可以生成一份秘钥，握手结束后的应用层数据都是使用这个秘钥进行对称加密。为什么要使用三个随机数呢？这是因为 SSL/TLS 握手过程的数据都是明文传输的，并且多个随机数种子来生成秘钥不容易被暴力破解出来。客户端将 PreMaster Key 传给服务端的过程如下图所示：
客户端收到服务器所有响应消息后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。
如果证书没有问题，客户端就会从证书中取出服务器的公钥，即server 消息中携带的public key值。然后，根据已经收到的三个随机数计算出加密密钥，对握手信息进行加密通信，然后向服务器发送上面抓包中三项信息内容。
该步骤中的随机数，是整个握手阶段出现的第三个随机数，又称”pre-master key”。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把”会话密钥”。
Certificate verify（可选）
只有在客户端发送了自己证书到服务器端，这个消息才需要发送。其中包含一个签名，对从第一条消息以来的所有握手消息的HMAC值（用master_secret）进行签名。
SSL建立第四阶段：Client/Server 发送Change Cipher Spec报文，Client/Server 发送Encrypted Handshake Message报文,完成握手协议，建立SSL连接。
客户端启动SSL握手第4阶段，使服务器结束。该阶段分为4步，前2个消息来自客户机，后2个消息来自服务器。
1.建立起一个安全的连接，客户端发送一个Change Cipher Spec消息，并且把协商得到的CipherSuite拷贝到当前连接的状态之中
2.客户端用新的算法、密钥参数发送一个Finished消息，这条消息可以检查密钥交换和认证过程是否已经成功。其中包括一个校验值，对客户端整个握手过程的消息进行校验。
3.服务器发送Change Cipher Spec消息，检查密钥交换和认证过程是否已经成功，验证通过后，server告知client从现在开始发送的消息都是加密过的。
4.服务器发送Finished消息，客户端和服务器可以交换应用层数据进行通信。
Clinet发送Change Cipher Spec
客户端通知服务端后面再发送的消息都会使用前面协商出来的秘钥加密了，是一条事件消息。client指示Server从现在开始发送的消息都是加密过的。
client发送Encrypted Handshake Message
这一步对应的是 Client Finish 消息，客户端握手结束通知, 表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验（使用HMAC算法计算收到和发送的所有握手消息的摘要，然后通过RFC5246中定义的一个伪函数PRF计算出结果，加密后发送。此数据是为了在正式传输应用数据之前对刚刚握手建立起来的加解密通道进行验证。）
Server发送Change Cipher Spec
服务器用私钥解密加密的 Pre-master 数据，基于之前交换的两个明文随机数 random_C 和 random_S，计算得到协商密钥:enc_key=Fuc(random_C, random_S, Pre-Master);计算之前所有接收信息的 hash 值，然后解密客户端发送的 encrypted_handshake_message，验证数据和密钥正确性;
验证通过后，Server告知client从现在开始发送的消息都是加密过的。
这次Sever一个报文共发送的2个消息：Change Cipher Spec和Finish。
Server发送Encrypted Handshake Message
这一步对应的是 Server Finish 消息，服务端握手结束通知。
1.使用私钥解密加密的Pre-master数据，基于之前(Client Hello 和 Server Hello)交换的两个明文随机数 random_C 和 random_S，计算得到协商密钥:enc_key=Fuc(random_C, random_S, Pre-Master);
2.计算之前所有接收信息的 hash 值，然后解密客户端发送的encrypted_handshake_message，验证数据和密钥正确性;
3.发送一个 ChangeCipherSpec（告知客户端已经切换到协商过的加密套件状态，准备使用加密套件和 Session Secret加密数据了）
4.服务端也会使用 Session Secret 加密一段 Finish 消息发送给客户端，以验证之前通过握手建立起来的加解密通道是否成功。
根据之前的握手信息，如果客户端和服务端都能对Finish信息进行正常加解密且消息正确的被验证，则说明握手通道已经建立成功，接下来，双方可以使用上面产生的Session Secret对数据进行加密传输了。
SSL传输数据：Application Data
Application Data
到这里，双方已安全地协商出了同一份秘钥，所有的应用层数据都会用这个秘钥加密后再通过 TCP 进行可靠传输。
