404 Not Found
404 Not Found
The requested URL was not found on this server.
您要找的内容已被删除404 Not Found
404 Not Found
The requested URL was not found on this server.
您要找的内容已被删除The page is temporarily unavailable
nginx error!
The page you are looking for is temporarily unavailable.
Please try again later.
Website Administrator
Something has triggered an error on your
This is the default error page for
nginx that is distributed with
It is located
/usr/share/nginx/html/50x.html
You should customize this error page for your own
site or edit the error_page directive in
the nginx configuration file
/etc/nginx/nginx.conf.1456人阅读
当我们在浏览器输入URL点击确认后，浏览器展示出网页信息。可你曾想过这其中的过程是怎样的？理论性较强的朋友可能知道后续DNS会解析地址，然后TCP/IP三次握手建立起连接，紧接着客户端与服务器开始传输数据。不错，大致过程确实如此，可终究“眼见为实”，此篇文章重点在于亲自实践，通过WireShark抓包来图解探索网络请求的整个过程，通过实践来更透彻的认识网络模型、三次握手、滑动窗口协议等理论知识在实际中的运用。
此篇涉及到的知识点如下：
五层网络模型
TCP/IP三次握手
滑动窗口协议
WireShark抓包探索
一. 网络理论知识
在使用WireShark抓包实践之前，先来学习以下基础的理论知识点作为基础。
1. 网络模型
首先通过一个简单的例子来了解网络架构，如下图所示，Tom想给Jerry发送一份可靠、安全的信息，但是实际上拥有的物理线路并非是可靠安全的，我们需要解决的就是在此之上建立一个可靠、安全的传输渠道。
（1）网络传输架构
而其中依赖的就是七层架构，来具体查看其原理：
物理层：最下面一层节点之间不可靠、安全的传输就是物理层。
数据链路层： 首先搭了一个数据链路层，既然节点之间传输数据不安全，那么需要一个单位（数据包），通过奇偶校验或其它方法来检验包是否正确，由此完成了一个节点到另外一个节点之间数据包的传递。
网络层： 如果Tom和Jerry都在一个房间内，那么数据链路层足够，可是如果是其它地区、国家，这就不仅仅是两个节点之间传输，需要一个网络层。网络层有路由，Tom会把包发给房间的路由器，路由器再传输给其它路由，辗转很多层后最后到Jerry所在的电脑上。这就是网络层的工作，同时为了标识在网络层中的各个节点，使用了IP协议，使每个节点都有IP地址。
传输层： 虽然在数据链路层可以确定包是否正确， 但不能保证是相对可靠的，此时需要重传机制在错误时可以自动重传这个包，而不需要Tom人工确认，这就需要传输层。由此产生了对应的TCP、UDP协议。TCP协议是基于连接的，在Tom和Jerry传输之间建立一个可靠的连接，在此连接上传输数据。
应用层：以上过程确实可以传输可靠的数据，但是这个数据是为哪个应用服务的呢？是HTTP还是STP或者email协议，这就是应用层。
由此完成了上图中的五层架构，而七层架构中的其余两层被淡化，暂时不列出来，但是以上架构是解决网络问题最优方案吗？
并非如此，现在已知五层或七层架构是建立与不可靠、不安全的传输上，那为何不从最底层使得它可靠、安全呢？但是在网络发展过程中都是一层层地来解决问题，时从实践问题出发而并非理论，所以才有了往上叠加的网络协议、架构。回望计算机的历史发展，都是一层层地迭代进化而不是一开始就可以设计出完美方案，例如Java语言的泛型。
（2）网络传输的可靠、安全性
一开始就强调了网络传输并非是可靠、安全的，具体体现如下：
不可靠性：（在TCP协议中对以下3个不可靠因素提供了解决方案）
丢包、重复包：发送包对方并未收到或是收到重复包。
出错：传输时出错，只能通过重传来解决。
乱序：包是按照顺序发送的，对方接收时顺序打乱。
不安全性：
网络传输一定是一个不安全的线路，因为网络层将数据发送给另外一个节点，需要经过很多路由器，每一个路由都有可能被黑客监听。（不同于电话传输，所有的交换机在机房，网络上只需要一个无线路由器就可以监听手机的对外传输）
中间人攻击
2. TCP三次握手(TCP Three-way Handshake)
TCP是主机对主机层的传输控制协议，提供可靠的连接服务，采用三次握手确认建立一个连接。
（1）TCP标志位
TCP在其协议头中使用大量的标志位或者说1位（bit）布尔域来控制连接状态，一个包中有可以设置多个标志位。
位码即TCP标志位，有6种标示：
SYN (synchronous)： 创建连接
ACK (acknowledgement）： 确认接收到的数据)
PSH (push)：传送
FIN (finish)：结束连接
RST (reset)：重置
URG (urgent)：紧急
Sequence number(顺序码)
Acknowledge number(确认码)
（2）握手过程
定义：三次握手，是指建立一个TCP连接时，需要客户端和服务器总共发送3个包。
目的：是连接服务器指定端口，建立TCP连接,并同步连接双方的序列号和确认号并交换 TCP 窗口大小信息
在socket编程中，客户端执行connect()时，将触发三次握手。
第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。完成三次握手，客户端与服务器开始传送数据.
3. 滑动窗口协议
此部分进行的讲解重心还是放在网络传输的可靠性，仔细探究TCP协议是如何解决网络传输的不可靠问题，其中有个非常关键部分——滑动窗口协议，同时可验证网络学科的实践性、工程性。
（1）滑动窗口协议的特征定义
TCP协议中使用
维持发送方/接收方缓存区
此缓存区主要用于解决网络传输的不可靠问题，在上一点已经介绍过网络传输的不可靠问题，如丢包、重复包、出错等，在TCP协议中发送方、接收方各自维护自己的缓存区，互相商定包的重传机制，由此解决不可靠问题。
（2）提出问题
如果没有滑动窗口协议，如何保证接收方能够收到正确有序的包？
如上图所示，发送方发送包1，接收方确认包1，发送包2，确认包2，这样即可解决不可靠性问题。但同时此过程的问题十分明显：吞吐量低，必须要等接收方确认完后才能发送下一个包。试考虑，若能连发几个包，接收方可以同时确认，这样效率岂不更高？
（3）简单改进
在此问题上，出现了以下改进：发送方可以同时发多个包，接收方一起确认。
（4）深度改进——滑动窗口实现
由此又衍生出一个问题，同时发包的数量多少才会是最优方案呢？例如发送方同时发送包1、2，在获得接收方确认包1消息后，能否不等包2确认信息，直接发送包3呢？
这样很自然地思考到了“滑动窗口实现”。以下有16个数据包，发送方希望按照顺序发送，在接收方收到每个包后都逐一给予确认：
初始：（窗口为4到7）
1、2、3包已发送并且获取发送方Ack确认；
4、5、6、7包已发送但尚未获取发送方Ack确认；
8、9、10包待发送；
而11、12、13、14、15、16包未发送甚至都没有装入内存；
正常：（窗口为5到9）
1、2、3、4包已发送并且获取发送方Ack确认；
5、6、7、8、9包已发送但尚未获取发送方Ack确认；
10、11包待发送；
而12、13、14、15、16包未发送甚至都没有装入内存；
丢Ack：（窗口为5到11）
5、6、7、8、9包未收到Ack（丢Ack），在等待过程又发送了10、11包，此时窗口已满，无法读进包12，只能等待Ack。如果真的是丢包，始终无法收到Ack，此时超时重传机制会从包5开始重新发送。（注意，这里的Ack是按照顺序发送的！）
重发： （窗口为9到15）
5、6、7、8包获取发送方Ack确认；
9、10、11、12、13包已发送但尚未获取发送方Ack确认；
13、14包待发送；
而16包未发送甚至都没有装入内存；
运用工程学的思想来考虑滑动窗口机制较为容易，为了增加线路的吞吐量，改进原版方案，令发送方同时发送包；为了衡量同时发送的数量达到吞吐量最优解，从而引进滑动窗口机制；为了解决丢包等不可靠性问题导致发送方无法收到接收方的Ack，又引进了重发机制。以上一系列过程使得整个传输过程更加可靠。
TCP采用的滑动窗口？
a. 是3位的滑动窗口 ( N )
b. 仅用于流量控制 ( N )
c. 在传输过程中窗口大小不调整 ( N )
d. 大小为0是合法的 ( Y )
二. WireShark 网络抓包示例
WireShark是很有名的抓包软件，基本的操作指导不做过多讲解，这里主要将重点放在其抓包的数据，由此分析网络模型组成及相关原理。
1. 网络请求访问（73、74号DNS包）
首先打开wireshark软件，会出现许多接口interface，选择本机连接的网络进行捕获，访问新浪网：（注意这里的地址是国际版的，未带cn），这里建议在Chrome中的隐身窗口中访问，避免浏览器中缓存的干扰！访问后停止捕获。在其内容中搜索字符串“sina”，第一条就是捕获到的数据，点击查看具体内容组成。
（1） 解析73号DNS数据包
这是一个DNS数据包，代表若我们要访问新浪网，首先要通过DNS的请求然后到新浪网的IP地址，来具体查看数据包所含内容：
a. Frame 73: 80 bytes on wire (640 bits), 80 bytes captured (640 bits) on interface 0
这是物理层，Frame 73代表这是第73号数据包，大小为80，内容如下图所示，
b. Ethernet II, Src: IntelCor_37:44:c0 (34:de:1a:37:44:c0), Dst: HuaweiTe_71:8a:98 (00:46:4b:71:8a:98)
数据链路层的报文头及相关协议（ 还有PPP 和PPPOE协议），它的Src是IntelCor_37:44:c0 ，这其实是我的笔记本，windows系统（若是mac，则是Apple开头的）；而Dst中的是我电脑连接的网络路由。
虽然这是DNS的一个query，但是无法访问我的路由，最终是传到外面DNS的路由，在数据链路层只是将包从笔记本传到路由，这个包会由路由器进行转发。
c. Internet Protocol Version 4, Src: 27.18.155.45, Dst: 202.103.24.68
网络层即IP层的头。很熟悉的IPV4协议，Src是我连接的Netkeeper网络的IPV4地址，Dst是DNS服务器地址。
d. User Datagram Protocol, Src Port: 60889, Dst Port: 53
传输层中UDP协议的头。 这个DNS的请求是作为一个UDP包发送，不需要预先建立连接。
e. Domain Name System (query)
DNS的query内容。以上讲解的UDP包中的内容就是DNS的query部分，由以下二进制数据表示，根据协议会规定每个字节代表什么含义，wireshark会翻译出每个字节的含义，例如下图中：
Transaction ID是0xe231
Questions数量为1，www.sina.com新浪网的地址。（意味着还可以有多个Questions）
Response响应在65号包。
（以上字节内容都是wireshark分析得出的结果）
（2）解析74号DNS数据包
由以上分析可得响应内容在74号数据包，来查看：（只解释重点内容）
Ethernet II, Src: HuaweiTe_71:8a:98 (00:46:4b:71:8a:98), Dst: IntelCor_37:44:c0 (34:de:1a:37:44:c0)
数据链路层的报文头及相关协议（ 还有PPP 和PPPOE协议），很明显后面的src内容是本地路由。
Internet Protocol Version 4, Src: 202.103.24.68, Dst: 27.18.155.45
IP层。scr是DNS服务器地址，Dst是本机IP，代表dns将包发送到本机。
Domain Name System (response)
应用层。查看下图DNS的response内容，Queries是本机请求新浪IP，而Answer有3个地址。
对比查看，发现DNS的response中的Answer提供的IP地址（66.102.251.33）与75号TCP数据包IP相对应，说明我们可以从Answer第三个信息连上！获取到新浪网的IP地址后，需要开始建立连接。
2. 与新浪网建立连接，进行网络协议中的3次握手（75、76、77号TCP包）
经过以上分析后，接下来在wireshark中搜索只有关于IP地址的信息（搜索ip.addr==66.102.251.33）。如下图，这样即可查看笔记本电脑与新浪网的交互过程：
来分析75、76、77号TCP包，查看其Info部分：
第一个包标志为 [SYN]
第二个包标志为
[SYN，ACK]
第三个包标志为
对网络知识有过了解的肯定知道这就是网络协议中的3次握手，来依次查看：
（1）75号TCP包
此包是第一次握手具体内容，来查看：
数据链路层（Ethernet II）：包是从本机发送到路由。
网络层（IPV4）：将包发送给新浪网。
传输层（TCP）：（查看下图）
Destination Port目的地端口号为80， 即试图和新浪网的80号端口连接，80号端口是HTTP协议的端口，浏览器若要访问需要从HTTP获取信息。
Sequence number 是包的编号为0，在博文的第二大点中滑动窗口协议已经介绍包的编号机制。
Acknowledgment number为0，因为目前并未收到Ack。
Flags 设置为SYN，代表连接的请求。
Window size value是滑动窗口的大小，是8192。
TCP Segment Len 为0，因为次请求只带了一个头部，内容为0，所以此包的长度除去头部之外为0。
（2）76号TCP包
继续查看第二次握手新浪网响应的包是什么，直接查看重点部分TCP内容如下：
Acknowledgment number为1，在TCP中1并不表示收到了包，而是说在等待、期待发送包，因为之前已经发送了第一个包，意味着包0已经收到，现在期待收包1。
Flags 设置为（SYN，Ack），代表已经收到了连接请求，并且愿意进行连接
Window size value是新浪网的滑动窗口大小，是4320。
（3）77号TCP包
继续查看第三次握手内容，我们直接查看重点部分TCP内容如下：
Sequence number 是包的编号为1
Acknowledgment number为1，说明收到了新浪网的0号包，现在期待1号包的来临。
Flags 设置为（Ack），代表确认连接。
Window size value调整滑动窗口大小为17280。
当此包被发送出去后，3次握手过程完成，本机和新浪网之间的消息在一个很可靠的TCP连接上进行。
3. 成功建立连接，开始GET请求资源（78号HTTP包）
接下来可以发送HTTP协议，查看wireshark之后证实我们的言论，接下来确实是进行Http协议上的Get请求，直接查看78号HTTP包中重点内容。
（1）TCP内容
TCP Segment Len长度不再为0，而是369。
Sequence number 仍然是1，在TCP协议中并非按照1、2、3….这样来标识，而是按照发送字节的大小。例如当前是1，加上此包本身长度为369，所以Next sequence number 是370。
Acknowledgment number为1
（2）HTTP请求内容
如下图是一些基本的http请求内容，例如host主机名和请求的基本参数，稍作了解即可。
4. 本机与新浪网交互 —— 资源发送与确认Ack
（1）79号TCP包
TCP中内容：（这里需要重点关注此点即可）
查看上图，Acknowledgment number 为 370 ，表示从0~369之间的数据已接收到，从370开始发送。
（2）80、81、82号TCP包（发送）
接下来查看80、81、82号TCP三个包，是新浪网返回的数据，通过上图可知每个包大小都是1502，表示一个包发不完，所以分成几个包来发送。这里依旧将重点放在TCP内容中：
Sequence number字段：
根据下图这三个包中的Sequence number变化可知，3个包传递的TCP内容长度皆为1440，顺序号从1开始，逐渐变化增加。重点注意此字段变化：1 -&1441 -& 2881。（此部分结合后一点讲解证实了滑动窗口协议）
TCP segment data
TCP中传输的内容绝对是不会以明文的方式，通过此字段可知，Encoding编码方式是gzip，所以显示的数据都是乱码，浏览器收到后会自动进行解码。
（3）83、92TCP包（Ack）
重新回顾滑动窗口协议，新浪网在发送了80、81、82号TCP包后，需要等待接收方Ack！
下图是83、92TCP包中的TCP重点内容，这是接收方的Ack：
83包中的Acknowledgment number 为2881，注意对应上一点讲解的80、81、81号TCP包中的Next Sequence number字段可知：81个包中Next Sequence number长度为2881，意味着已有0~2880长度数据，所以83包的Ack代表同时确认了新浪网发送的81、82这两个包！
92包中的Acknowledgment number 为4321，对应着82号TCP包中的Next Sequence number字段。代表92包的Ack代表确认了新浪网发送的83包！
有时候是同时Ack两个包，有时候是Ack一个包，以上过程正是之前讲解的滑动窗口协议中的部分呈现。
（4）总结发送与确认Ack
通过以上2、3小点的总结，了解了发送和Ack确认这样一个交互的过程，查看下图来总结这一系列的交互过程：
新浪网发送80、81、82号TCP包。
83号包同时确认Ack 80、91号两个TCP包，92号包确认Ack82号TCP包。
新浪网发送93、94号TCP包。
95号包确认Ack93、94号TCP包。
5. HTTP中GET请求200，成功访问新浪网（96号HTTP包、189号TCP包）
（1）96号HTTP包 ——- Get请求成功200
上图中的红框部分表示总共发送了6个包来传输HTTP文件，注意除了以上分析的80、81、82、93、94号TCP包，96号HTTP包自身也包含在内，每个包所含内容是1440字节（除了最后一个HTTP包是1140字节），总长度为8340字节！
如上图所示，此时也可以查看Line-based text data: text/html部分，是我们十分熟悉的HTML文件，这是新浪网首页的HTML。
（2）189号TCP包 —— 确认Ack
189号TCP包再次对传输的数据进行了确认Ack。重点查看TCP内容中的Acknowledgment number为 8341 ，表示已经收到8340字节，下一个数据从8341开始，正好对应了96号HTTP包中的长度树也是8340，新浪网首页请求过程成功探索完毕！
由于本机与新浪网在TCP3此握手后的建立连接仍然有效，所以后续又HTTP请求GET一张图片，再经过以上系列分析后，后面的包内容就清晰明了：
新浪网发送两个TCP数据包
接收方确认Ack
HTTP请求成功200
接收方再次确认Ack
以上部分1~5点为WireShark抓包探索网络请求的全过程，自行总结归纳分为以上5个部分，总结的步骤图示如下：
网络请求过程人人似乎都略懂一二，此过程看似简单却又复杂，其完整过程不容易阐明清楚。所以博主推荐各位可亲自实践抓包捕获，体会后续DNS会解析地址，然后TCP/IP三次握手建立起连接，紧接着客户端与服务器开始传输数据的过程。这样对网络模型、三次握手、滑动窗口协议等理论知识有更透彻的认识。
若有错误，欢迎指教~
文章：14篇
阅读：23926
阅读：9458
阅读：6326