下载一个Web页面。我们的场景: 一名学生Bob将他的便携机与学校的以太网交换机相连,下载一个
Web
页面(比如 www.google.com
主页)。如我们所知,为满足这个看起来简单的请求,背后隐藏了许多细节。
内部涉及知识:
1、七层参考模型及IP讲解
2、TCP三次握手讲解
3、TCP四次挥手讲解及抓包分析
4、DHCP协议讲解及抓包分析
5、静态综合实验讲解
7、静态路由讲解
8、RIP路由信息协议讲解
9、动态路由协议讲解
10、抓包进行分析RIP以及OSPF的包
11、动态路由OSPF配置综合实验讲解
12、Vlan虚拟局域网技术讲解
13、ACL访问控制列表讲解
14、NAT技术讲解
15、网络综合实验讲解
一、准备:DHCP、UDP、IP 和以太网
我们假定Bob
启动他的便携机,然后将其用一根以太网电缆连接到学校的以太网交换机,交换机又与学校的路由器相连,如上图所示。学校的这台路由器与一个ISP
连接,本例中ISP
为comcast.net
。在本例中,comcastnet
为学校提供了DNS
服务;所以,DNS
服务器驻留在 Comcast
网络中不学校网络。我们将假设DHCP
服务器运行中,就像常见情况那样。
当Bob
首先将其便携机与网络连接时,没有IP
地址他就不能做任何事情(例如下载个Web
网页)。所以,Bob
的便携机所采取的一个网络相关的操作是运行 DHCP
协议,以从本地 DHCP
服务器获得一个IP
地址以及其他信息。
- 1)
Bob
便携机上的操作系统生成一个DHCP
请求报文,并将这个报文放入具有目的端口67
(DHCP
服务器) 和源端口68
(DHCP
客户)的UDP
报文段(该UDP
报文段则被放置在一个具有广播IP
目的地址 (255.255.255.255
)和源IP
地址0.0.0.0
的IP
数据报中,因为Bob
的便携机还没有一个IP
地址。 - 2)包含
DHCP
请求报文的IP
据报则被放置在以太网中。该以太网具有目的MAC
地址FF:FF:FF:FF:FF:FF
,使该将广播到与交换机连接的所有没备(如果顺利的话也包括DHCP
服务器):该帧的源MAC
地址是Bob
便携机的MAC
地址00 : 16 : D3 : 23 : 68 : 8A
- 3)包含
DHCP
请求的广播以太网是第一个由Bob
便携机发送到以太网交换机的顿该交换机在所有的出端口广播入帧,包括连接到路由器的端口。 - 4)路由器在它的具有
MAC
地址00:22:6B:45:1F
的接口接收到该广播以太网喷中包含DHCP
请求,并且从该以太网帧,该帧中抽取出IP
数据报。该数据报的广播IP
目的地址指示了这个IP
数据报应当由在该节点的高层协议处理,因此该数据报的载荷 (一个UDP
报文段)被分解向上到达UDP
,DHCP
请求报文从此UDP
报文段中抽取出来,此时DHCP
服务器有了DHCP
请求报文。 - 5)我们假设运行在路由中的
DHCP
服务器能够以CIDR
块68.85.2.0/24
分配IP
地址。所以本例中,在学校内使用的所有IP
地址都在Comeast
的地址块中。我们假设DHCP
服务器分配地址68.85.2.101
给Bob
的便携机。DHCP
服务器生成包含这个IP
地址以及DNS
服务器的IP
地址 (68.87.71.226
)、默认网关路由器的IP
地址(68.85.2.1
)和子网块(68.85.2.0/24
)(等价为“网络掩码”)的一个DHCP ACK
报文。该DHCP
报文被放人一个UDP
报文段中,UDP
报文段被放入一个IP
数据报中,IP
数据报再被放人一个以太网中。这个以太网顿的源MAC
地址是路由器连到归属网络时接口的MAC
地址(00:22:6B:45:1F:1B
),目的MAC
地址是Bob
便携机的MAC
地址(00:16:D3:23:68:8A
)。 - 6)包含
DHCP ACK
的以太网帧由路由器发送给交换机。因为交换机是自学习的,并且先前从Bob
便携机收到(包含DHCP
请求的)以太网帧,所以该交换机知道寻址到00:16:D3:23:68:8A
的帧仅从通向Bob
便携机的输出端口转发。 - 7)
Bob
便携机接收到包含DHCP ACK
的以太网帧,从该以太网帧中抽取IP
数据报,从IP
数据报中抽取UDP
报文段,从UDP
报文段抽取DHCP ACK
报文。Bob
的DHCP
客户则记录下它的IP
地址和它的DNS
服务器的IP
地址。它还在其IP
转发表中安装默认网关的地址。Bob
便携机将向该默认网关发送目的地址为其子网68.85.2.0/24
以外的所有数据报。此时,Bob
便携机已经初始化好它的网络组件,并准备开始处理Web
网页获取。
二、仍在准备:DNS和ARP
当Bob
将www.google.com
的URL
键入其Web
浏览器时,他开启了一长串事件,这将导致谷歌主页最终显示在其Web
浏览器上。Bob
的Web
浏览器通过生成一个TCP
套接字开始了该过程,套接字用于向www.google.com
发送HTTP
请求。为了生成该套接字,Bob
便携机将需要知道www.google.com
的IP
地址。使用DNS
协议提供这种名字到IP
地址的转换服务。文章来源:https://www.toymoban.com/news/detail-574948.html
- 8)
Bob
便携机上的操作系统因此生成一个DNS
查询报文,将字符串www.google.com
放入DNS
报文的问题段中。该DNS
报文则放置在一个具有53
号(DNS
服务器)目的端口的UDP
报文段中。该UDP
报文段则被放入具有IP
目的地址68.87.71.226
(在第5步中DHCP ACK
返回的DNS
服务器地址)和源IP
地址68.85.2.101
的IP
数据报中。 - 9)
Bob
便携机则将包含DNS
请求报文的数据报放入一个以太网帧中。该帧将发送(在链路层寻址)到Bob
学校网络中的网关路由器。然而,即使Bob
便携机经过上述第5步中的DHCP ACK
报文知道了学校网关路由器的IP
地址(68.85.2.1
),但仍不知道该网关路由器的MAC
地址。为了获得该网关路由器的MAC
地址,Bob
便携机将需要使用ARP
协议。 - 10)
Bob
便携机生成一个具有目的IP
地址68.85.2.1
(默认网关)的ARP
查询报文,将该ARP
报文放置在一个具有广播目的地址(FF:FF:FF:FF:FF:FF
)的以太网帧中,并向交换机发送该以太网帧,交换机将该帧交付给所有连接的设备,包括网关路由器。 - 11)网关路由器在通往学校网络的接口上接收到包含该
ARP
查询报文的帧,发现在ARP
报文中目标IP地址68.85.2.1
匹配其接口的IP
地址。网关路由器因此准备一个ARP
回答,指示它的MAC
地址00:22:6B:45:1F:1B
对应IP
地址68.85.2.1
。它将ARP
回答放在一个以太网帧中,其目的地址为00:16:D3:23:68:8A
(Bob
便携机),并向交换机发送该帧,再由交换机将帧交付给Bob
便携机。 - 12)
Bob
便携机接收包含ARP
回答报文的帧,并从ARP
回答报文中抽取网关路由器的MAC
地址(00:22:6B:45:1F:1B
)。 - 13)
Bob
便携机现在(最终!)能够使包含DNS
查询的以太网帧寻址到网关路由器的MAC
地址。注意到在该帧中的IP
数据报具有IP
目的地址68.87.71.226
(DNS
服务器),而该帧具有目的地址00:22:6B:45:1F:1B
(网关路由器)。Bob
便携机向交换机发送该帧,交换机将该帧交付给网关路由器。
三、仍在准备:域内路由选择到DNS服务器
- 14)网关路由器接收该帧并抽取包含
DNS
查询的IP数据报。路由器查找该数据报的目的地址(68.87.71.226
),并根据其转发表决定该数据报应当发送到Comcast
网络中最左边的路由器。IP数据报放置在链路层帧中,该链路适合将学校路由器连接到最左边Comcast
路由器,并且该帧经这条链路发送。 - 15)在
Comcast
网络中最左边的路由器接收到该帧,抽取IP
数据报,检查该数据报的目的地址(68.87.71.226
),并根据其转发表确定出接口,经过该接口朝着DNS
服务器转发数据报,而转发表已根据Comcast
的域内协议(如RIP
、OSPF
或IS-IS
)以及因特网的域间协议BGP
所填写。 - 16)最终包含
DNS
查询的IP数据报到达了DNS
服务器。DNS
服务器抽取出DNS
查询报文,在它的DNS
数据库中查找名字www.google.com
,找到包含对应www.google.com
的IP
地址(64.233.169.105
)的DNS
源记录。(假设它当前缓存在DNS
服务器中。)前面讲过这种缓存数据源于google.com
的权威DNS
服务器。该DNS
服务器形成了一个包含这种主机名到IP
地址映射的DNS
回答报文,将该DNS
回答报文放入UDP
报文段中,该报文段放入寻址到Bob
便携机(68.85.2.101
)的IP
数据报中。该数据报将通过Comcast
网络反向转发到学校的路由器,并从这里经过以太网交换机到Bob
便携机。 - 17)
Bob
便携机从DNS
报文抽取出服务器www.google.com
的IP
地址。最终,在大量工作后,Bob
便携机此时准备接触www.google.com
服务器!
四、Web客户-服务器交互:TCP和HTTP
- 18)既然
Bob
便携机有了www.google.com
的IP
地址,它能够生成TCP
套接字,该套接字将用于向www.google.com
发送HTTP GET
报文。当Bob
生成TCP
套接字时,在Bob
便携机中的TCP
必须首先与www.google.com
中的TCP
执行三次握手。Bob
便携机因此首先生成一个具有目的端口80
(针对HTTP
的)的TCP SYN
报文段,将该TCP
报文段放置在具有目的IP地址64.233.169.105
(www.google.com
)的IP
数据报中,将该数据报放置在MAC
地址为00:22:6B:45:1F:1B
(网关路由器)的帧中,并向交换机发送该帧。 - 19)在学校网络、
Comcast
网络和谷歌网络中的路由器朝着www.google.com
转发包含TCP SYN
的数据报,使用每台路由器中的转发表,如前面步骤14~16那样。前面讲过支配分组经Comcast
和谷歌网络之间域间链路转发的路由器转发表项,是由BGP
协议决定的。 - 20)最终,包含
TCP SYN
的数据报到达www.gogole.com
。从数据报抽取出TCP SYN
报文并分解到与端口80
相联系的欢迎套接字。对于谷歌HTTP
服务器和Bob
便携机之间的TCP
连接生成一个连接套接字。产生一个TCP SYNACK
报文段,将其放人向Bob
便携机寻址的一个数据报中,最后放入链路层帧中,该链路适合将www.google.com
连接到其第一跳路由器。 - 21)包含
TCP SYNACK
报文段的数据报通过谷歌、Comcast
和学校网络,最终到达Bob
便携机的以太网卡。数据报在操作系统中分解到步骤18
生成的TCP
套接字,从而进入连接状态。 - 22)借助于
Bob
便携机上的套接字,现在(终于!)准备向www.google.com
发送字节了,Bob
的浏览器生成包含要获取的URL
的HTTP GET
报文。HTTP GET
报文则写人套接字,其中GET
报文成为一个TCP
报文段的载荷。该TCP
报文段放置进一个数据报中,并交付到www.google.com
,如前面步骤18~20所述。 - 23)在
www.google.com
的HTTP
服务器从TCP
套接字读取HTTP GET
报文,生成一个HTTP
响应报文,将请求的Web
页内容放入HTTP
响应体中,并将报文发送进TCP
套接字中。 - 24)包含
HTTP
回答报文的数据报通过谷歌、Comcast
和学校网络转发,到达Bob
便携机。Bob
的Web
浏览器程序从套接字读取HTTP
响应,从HTTP
响应体中抽取Web
网页的html,并最终(终于!)显示了Web
网页。
上面的场景已经涉及许多网络基础,同时上述例子看起来是尽可能详尽,我们已经忽略了一些可能的附加协议(例如,运行在学校网关路由器中的NAT,到学校网络的无线接入,接入学校网络或对报文段或数据报加密的安全协议,网络管理协议),以及人们将会在公共因特网中遇到的一些考虑(Web缓存,DNS等级体系)。文章来源地址https://www.toymoban.com/news/detail-574948.html
五、HTTP请求响应格式
Requests部分
Header | 解释 | 示例 |
---|---|---|
Accept | 指定客户端能够接收的内容类型 | Accept: text/plain, text/html |
Accept-Charset | 浏览器可以接受的字符编码集 | Accept-Charset: iso-8859-5 |
Accept-Encoding | 指定浏览器可以支持的web服务器返回内容压缩编码类型。 | Accept-Encoding: compress, gzip |
Accept-Language | 浏览器可接受的语言 | Accept-Language: en,zh |
Accept-Ranges | 可以请求网页实体的一个或者多个子范围字段 | Accept-Ranges: bytes |
Authorization | HTTP授权的授权证书 | Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
Cache-Control | 指定请求和响应遵循的缓存机制 | Cache-Control: no-cache |
Connection | 表示是否需要持久连接。(HTTP 1.1默认进行持久连接) | Connection: close |
Cookie | HTTP请求发送时,会把保存在该请求域名下的所有cookie值一起发送给web服务器。 | Cookie: $Version=1; Skin=new; |
Content-Length | 请求的内容长度 | Content-Length: 348 |
Content-Type | 请求的与实体对应的MIME信息 | Content-Type: application/x-www-form-urlencoded |
Date | 请求发送的日期和时间 | Date: Tue, 15 Nov 2010 08:12:31 GMT |
Expect | 请求的特定的服务器行为 | Expect: 100-continue |
From | 发出请求的用户的Email | From: user@email.com |
Host | 指定请求的服务器的域名和端口号 | Host: www.zcmhi.com |
If-Match | 只有请求内容与实体相匹配才有效 | If-Match: “737060cd8c284d8af7ad3082f209582d” |
If-Modified-Since | 如果请求的部分在指定时间之后被修改则请求成功,未被修改则返回304代码 | If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
If-None-Match | 如果内容未改变返回304代码,参数为服务器先前发送的Etag,与服务器回应的Etag比较判断是否改变 | If-None-Match: “737060cd8c284d8af7ad3082f209582d” |
If-Range | 如果实体未改变,服务器发送客户端丢失的部分,否则发送整个实体。参数也为Etag | If-Range: “737060cd8c284d8af7ad3082f209582d” |
If-UnmodifiedSince | 只在实体在指定时间之后未被修改才请求成功 | If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
Max-Forwards | 限制信息通过代理和网关传送的时间 | Max-Forwards: 10 |
Pragma | 用来包含实现特定的指令 | Pragma: no-cache |
Proxy-Authorization | 连接到代理的授权证书 | Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
Range | 只请求实体的一部分,指定范围 | Range: bytes=500-999 |
Referer | 先前网页的地址,当前请求网页紧随其后,即来路 | Referer: http://www.zcmhi.com/archives/71.html |
TE | 客户端愿意接受的传输编码,并通知服务器接受接受尾加头信息 | TE: trailers,deflate;q=0.5 |
Upgrade | 向服务器指定某种传输协议以便服务器进行转换(如果支持) | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
User-Agent | User-Agent的内容包含发出请求的用户信息 | User-Agent: Mozilla/5.0 (Linux; X11) |
Via | 通知中间网关或代理服务器地址,通信协议 | Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |
Warning | 关于消息实体的警告信息 | Warn: 199 Miscellaneous warning |
Responses 部分
Header | 解释 | 示例 |
---|---|---|
Accept-Ranges | 表明服务器是否支持指定范围请求及哪种类型的分段请求 | Accept-Ranges: bytes |
Age | 从原始服务器到代理缓存形成的估算时间(以秒计,非负) | Age: 12 |
Allow | 对某网络资源的有效的请求行为,不允许则返回405 | Allow: GET, HEAD |
Cache-Control | 告诉所有的缓存机制是否可以缓存及哪种类型 | Cache-Control: no-cache |
Content-Encoding | web服务器支持的返回内容压缩编码类型。 | Content-Encoding: gzip |
Content-Language | 响应体的语言 | Content-Language: en,zh |
Content-Length | 响应体的长度 | Content-Length: 348 |
Content-Location | 请求资源可替代的备用的另一地址 | Content-Location: /index.htm |
Content-MD5 | 返回资源的MD5校验值 | Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== |
Content-Range | 在整个返回体中本部分的字节位置 | Content-Range: bytes 21010-47021/47022 |
Content-Type | 返回内容的MIME类型 | Content-Type: text/html; charset=utf-8 |
Date | 原始服务器消息发出的时间 | Date: Tue, 15 Nov 2010 08:12:31GMT |
ETag | 请求变量的实体标签的当前值 | ETag:“737060cd8c284d8af7ad3082f209582d” |
Expires | 响应过期的日期和时间 | Expires: Thu, 01 Dec 2010 16:00:00 GMT |
Last-Modified | 请求资源的最后修改时间 | Last-Modified: Tue, 15 Nov 201012:45:26 GMT |
Location | 用来重定向接收方到非请求URL的位置来完成请求或标识新的资源 | Location: http://www.zcmhi.com/archives/94.html |
Pragma | 包括实现特定的指令,它可应用到响应链上的任何接收方 | Pragma: no-cache |
Proxy-Authenticate | 它指出认证方案和可应用到代理的该URL上的参数 | Proxy-Authenticate: Basic |
refresh | 应用于重定向或一个新的资源被创造,在5秒之后重定向(由网景提出,被大部分浏览器支持) | Refresh: 5; url=http://www.zcmhi.com/archives/94.html |
Retry-After | 如果实体暂时不可取,通知客户端在指定时间之后再次尝试 | Retry-After: 120 |
Server | web服务器软件名称 | Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) |
Set-Cookie | 设置Http | Cookie Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1 |
Trailer | 指出头域在分块传输编码的尾部存在 | Trailer: Max-Forwards |
Transfer-Encoding | 文件传输编码 | Transfer-Encoding:chunked |
Vary | 告诉下游代理是使用缓存响应还是从原始服务器请求 | Vary: * |
Via | 告知代理客户端响应是通过哪里发送的 | Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |
Warning | 警告实体可能存在的问题 | Warning: 199 Miscellaneous warning |
WWW-Authenticate | 表明客户端请求实体应该使用的授权方案 | WWW-Authenticate: Basic |
到了这里,关于知识整合:Web页面请求的历程的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!