当我们在浏览器的地址栏输入 www.linux178.com ,然后回车,回车这一瞬间到看到页面到底发生了什么呢?

 

以下过程仅是个人理解:

 

域名解析 --> 发起TCP的3次握手 --> 建立TCP连接后发起http请求 --> 服务器响应http请求,浏览器得到html代码 --> 浏览器解析html代码,并请求html代码中的资源(如js、css、图片等) --> 浏览器对页面进行渲染呈现给用户

 

关于HTTP协议可以参考以下:

HTTP协议漫谈  http://kb.cnblogs.com/page/140611/

HTTP协议概览  http://www.cnblogs.com/vamei/archive/2013/05/11/3069788.html

了解HTTP Headers的方方面面  http://kb.cnblogs.com/page/55442/

 

以下就是上面过程的一一分析,我们就以Chrome浏览器为例:

 

1.域名解析

 

首先Chrome浏览器会解析 www.linux178.com 这个域名(准确的叫法应该是主机名)对应的IP地址。怎么解析到对应的IP地址?

 

① Chrome浏览器 会首先搜索浏览器自身的DNS缓存(缓存时间比较短,大概只有1分钟,且只能容纳1000条缓存),看自身的缓存中是否有www.linux178.com 对应的条目,而且没有过期,如果有且没有过期则解析到此结束。

    注:我们怎么查看Chrome自身的缓存?可以使用 chrome://net-internals/#dns 来进行查看

 

② 如果浏览器自身的缓存里面没有找到对应的条目,那么Chrome会搜索操作系统自身的DNS缓存,如果找到且没有过期则停止搜索解析到此结束.

     注:怎么查看操作系统自身的DNS缓存,以Windows系统为例,可以在命令行下使用 ipconfig /displaydns 来进行查看  

 

③ 如果在Windows系统的DNS缓存也没有找到,那么尝试读取hosts文件(位于C:\\Windows\\System32\\drivers\\etc),看看这里面有没有该域名对应的IP地址,如果有则解析成功。

 

④ 如果在hosts文件中也没有找到对应的条目,浏览器就会发起一个DNS的系统调用,就会向本地配置的首选DNS服务器(一般是电信运营商提供的,也可以使用像Google提供的DNS服务器)发起域名解析请求(通过的是UDP协议向DNS的53端口发起请求,这个请求是递归的请求,也就是运营商的DNS服务器必须得提供给我们该域名的IP地址),运营商的DNS服务器首先查找自身的缓存,找到对应的条目,且没有过期,则解析成功。如果没有找到对应的条目,则有运营商的DNS代我们的浏览器发起迭代DNS解析请求,它首先是会找根域的DNS的IP地址(这个DNS服务器都内置13台根域的DNS的IP地址),找打根域的DNS地址,就会向其发起请求(请问www.linux178.com这个域名的IP地址是多少啊?),根域发现这是一个顶级域com域的一个域名,于是就告诉运营商的DNS我不知道这个域名的IP地址,但是我知道com域的IP地址,你去找它去,于是运营商的DNS就得到了com域的IP地址,又向com域的IP地址发起了请求(请问www.linux178.com这个域名的IP地址是多少?),com域这台服务器告诉运营商的DNS我不知道www.linux178.com这个域名的IP地址,但是我知道linux178.com这个域的DNS地址,你去找它去,于是运营商的DNS又向linux178.com这个域名的DNS地址(这个一般就是由域名注册商提供的,像万网,新网等)发起请求(请问www.linux178.com这个域名的IP地址是多少?),这个时候linux178.com域的DNS服务器一查,诶,果真在我这里,于是就把找到的结果发送给运营商的DNS服务器,这个时候运营商的DNS服务器就拿到了www.linux178.com这个域名对应的IP地址,并返回给Windows系统内核,内核又把结果返回给浏览器,终于浏览器拿到了www.linux178.com  对应的IP地址,该进行一步的动作了。

 

 

注:一般情况下是不会进行以下步骤的

 

如果经过以上的4个步骤,还没有解析成功,那么会进行如下步骤(以下是针对Windows操作系统):

 

⑤ 操作系统就会查找NetBios name Cache(NetBIOS名称缓存,就存在客户端电脑中的),那这个缓存有什么东西呢?凡是最近一段时间内和我成功通讯的计算机的计算机名和Ip地址,就都会存在这个缓存里面。什么情况下该步能解析成功呢?就是该名称正好是几分钟前和我成功通信过,那么这一步就可以成功解析。

 

⑥ 如果第⑤步也没有成功,那会查询WINS 服务器(是NETBIOS名称和IP地址对应的服务器)

 

⑦ 如果第⑥步也没有查询成功,那么客户端就要进行广播查找

 

⑧ 如果第⑦步也没有成功,那么客户端就读取LMHOSTS文件(和HOSTS文件同一个目录下,写法也一样)

 

如果第八步还没有解析成功,那么就宣告这次解析失败,那就无法跟目标计算机进行通信。只要这八步中有一步可以解析成功,那就可以成功和目标计算机进行通信。

 

看下图抓包截图:

Linux虚拟机测试,使用命令 wget www.linux178.com 来请求,发现直接使用chrome浏览器请求时,干扰请求比较多,所以就使用wget命令来请求,不过使用wget命令只能把index.html请求回来,并不会对index.html中包含的静态资源(js、css等文件)进行请求。

wKioL1LSWzzxRParAAKbC85UJtE371.jpg

 

抓包分析:

 

① 号包,这个是那台虚拟机在广播,要获取192.168.100.254(也就是网关)的MAC地址,因为局域网的通信靠的是MAC地址,它为什么需要跟网关进行通信是因为我们的DNS服务器IP是外围IP,要出去必须要依靠网关帮我们出去才行。

② 号包,这个是网关收到了虚拟机的广播之后,回应给虚拟机的回应,告诉虚拟机自己的MAC地址,于是客户端找到了路由出口。

 

③ 号包,这个包是wget命令向系统配置的DNS服务器提出域名解析请求(准确的说应该是wget发起了一个DNS解析的系统调用),请求的域名www.linux178.com,期望得到的是IP6的地址(AAAA代表的是IPv6地址)

④ 号包,这个DNS服务器给系统的响应,很显然目前使用IPv6的还是极少数,所以得不到AAAA记录的

⑤ 号包,这个还是请求解析IPv6地址,但是www.linux178.com.leo.com这个主机名是不存在的,所以得到结果就是no such name

 

⑥ 号包,这个才是请求的域名对应的IPv4地址(A记录)

⑦ 号包,DNS服务器不管是从缓存里面,还是进行迭代查询最终得到了域名的IP地址,响应给了系统,系统再给了wget命令,wget于是得到了www.linux178.com的IP地址,这里也可以看出客户端和本地的DNS服务器是递归的查询(也就是服务器必须给客户端一个结果)这就可以开始下一步了,进行TCP的三次握手。

 

2.发起TCP的3次握手

 

拿到域名对应的IP地址之后,User-Agent(一般是指浏览器)会以一个随机端口(1024 < 端口 < 65535)向服务器的WEB程序(常用的有httpd,nginx等)80端口发起TCP的连接请求。这个连接请求(原始的http请求经过TCP/IP4层模型的层层封包)到达服务器端后(这中间通过各种路由设备,局域网内除外),进入到网卡,然后是进入到内核的TCP/IP协议栈(用于识别该连接请求,解封包,一层一层的剥开),还有可能要经过Netfilter防火墙(属于内核的模块)的过滤,最终到达WEB程序(本文就以Nginx为例),最终建立了TCP/IP的连接。

如下图:

wKioL1LSW6rjI1nhAAE63Uv8ZRY731.jpg

1) Client首先发送一个连接试探,ACK=0 表示确认号无效,SYN = 1 表示这是一个连接请求或连接接受报文,同时表示这个数据报不能携带数据,seq = x 表示Client自己的初始序号(seq = 0 就代表这是第0号包),这时候Client进入syn_sent状态,表示客户端等待服务器的回复

2) Server监听到连接请求报文后,如同意建立连接,则向Client发送确认。TCP报文首部中的SYN 和 ACK都置1 ,ack = x + 1表示期望收到对方下一个报文段的第一个数据字节序号是x+1,同时表明x为止的所有数据都已正确收到(ack=1其实是ack=0+1,也就是期望客户端的第1个包),seq = y 表示Server 自己的初始序号(seq=0就代表这是服务器这边发出的第0号包)。这时服务器进入syn_rcvd,表示服务器已经收到Client的连接请求,等待client的确认。

3) Client收到确认后还需再次发送确认,同时携带要发送给Server的数据。ACK 置1 表示确认号ack= y + 1 有效(代表期望收到服务器的第1个包),Client自己的序号seq= x + 1(表示这就是我的第1个包,相对于第0个包来说的),一旦收到Client的确认之后,这个TCP连接就进入Established状态,就可以发起http请求了。

看抓包截图:

wKiom1LSW9-BWZw6AAD7FV3OfS4963.jpg

 

⑨ 号包 这个就是对应上面的步骤 1)

⑩ 号包 这个对应的上面的步骤 2)

号包 这个对应的上面的步骤 3)

 

TCP 为什么需要3次握手?

 

举个例子:

 

假设一个老外在故宫里面迷路了,看到了小明,于是就有下面的对话:

 

老外: Excuse me,Can you Speak English?

小明: yes 。

老外: OK,I want ...

 

在问路之前,老外先问小明是否会说英语,小明回答是的,这时老外才开始问路

 

2个计算机通信是靠协议(目前流行的TCP/IP协议)来实现,如果2个计算机使用的协议不一样,那是不能进行通信的,所以这个3次握手就相当于试探一下对方是否遵循TCP/IP协议,协商完成后就可以进行通信了,当然这样理解不是那么准确。

 

为什么HTTP协议要基于TCP来实现?

 

目前在Internet中所有的传输都是通过TCP/IP进行的,HTTP协议作为TCP/IP模型中应用层的协议也不例外,TCP是一个端到端的可靠的面向连接的协议,所以HTTP基于传输层TCP协议不用担心数据的传输的各种问题。

 

3.建立TCP连接后发起http请求

 

进过TCP3次握手之后,浏览器发起了http的请求(看第包),使用的http的方法 GET 方法,请求的URL是 / ,协议是HTTP/1.0

 

wKioL1LSXDmgmVT_AAFUErYF2ys832.jpg

下面是第12号包的详细内容:

wKiom1LSXHiCgHkBAAKtTT2l-Ac152.jpg

 

以上的报文是HTTP请求报文。

 

那么HTTP请求报文和响应报文会是什么格式呢?

 

起始行:如 GET / HTTP/1.0 (请求的方法  请求的URL 请求所使用的协议)

头部信息:User-Agent  Host等成对出现的值

主体

 

不管是请求报文还是响应报文都会遵循以上的格式。

 

 

那么起始行中的请求方法有哪些种呢?

 

  GET: 完整请求一个资源 (常用)

  HEAD: 仅请求响应首部

  POST:提交表单  (常用)

  PUT: (webdav) 上传文件(但是浏览器不支持该方法)

  DELETE:(webdav) 删除

  OPTIONS:返回请求的资源所支持的方法的方法

  TRACE: 追求一个资源请求中间所经过的代理(该方法不能由浏览器发出)

 

那什么是URL、URI、URN?

 

URI  Uniform Resource Identifier 统一资源标识符

URL  Uniform Resource Locator 统一资源定位符

    格式如下:  scheme://[username:password@]HOST:port/path/to/source

                http://www.magedu.com/downloads/nginx-1.5.tar.gz

 

URN  Uniform Resource Name 统一资源名称

 

URL和URN 都属于 URI

 

为了方便就把URL和URI暂时都通指一个东西

 

 

请求的协议有哪些种?

 

有以下几种:

 

http/0.9: stateless

http/1.0: MIME, keep-alive (保持连接), 缓存

http/1.1: 更多的请求方法,更精细的缓存控制,持久连接(persistent connection) 比较常用

 

下面是Chrome发起的http请求报文头部信息

 

wKioL1LSXMqCjyIQAAESKm-mkV8876.jpg

 

其中

Accept  就是告诉服务器端,我接受那些MIME类型

Accept-Encoding  这个看起来是接受那些压缩方式的文件

Accept-Lanague   告诉服务器能够发送哪些语言

Connection       告诉服务器支持keep-alive特性

Cookie           每次请求时都会携带上Cookie以方便服务器端识别是否是同一个客户端

Host             用来标识请求服务器上的那个虚拟主机,比如Nginx里面可以定义很多个虚拟主机

                那这里就是用来标识要访问那个虚拟主机。

User-Agent       用户代理,一般情况是浏览器,也有其他类型,如:wget curl 搜索引擎的蜘蛛等    

 

 

条件请求首部:

If-Modified-Since 是浏览器向服务器端询问某个资源文件如果自从什么时间修改过,那么重新发给我,这样就保证服务器端资源

            文件更新时,浏览器再次去请求,而不是使用缓存中的文件

安全请求首部:

Authorization: 客户端提供给服务器的认证信息;

 

什么是MIME?

 

MIME(Multipurpose Internet Mail Extesions 多用途互联网邮件扩展)是一个互联网标准,它扩展了电子邮件标准,使其能够支持非ASCII字符、二进制格式附件等多种格式的邮件消息,这个标准被定义在RFC 2045、RFC 2046、RFC 2047、RFC 2048、RFC 2049等RFC中。 由RFC 822转变而来的RFC 2822,规定电子邮件标准并不允许在邮件消息中使用7位ASCII字符集以外的字符。正因如此,一些非英语字符消息和二进制文件,图像,声音等非文字消息都不能在电子邮件中传输。MIME规定了用于表示各种各样的数据类型的符号化方法。 此外,在万维网中使用的HTTP协议中也使用了MIME的框架,标准被扩展为互联网媒体类型。

 

MIME 遵循以下格式:major/minor 主类型/次类型 例如:

1
2
3
4

(c)2006-2024 SYSTEM All Rights Reserved IT常识