使用 HTTP 协议访问 Web

Web 通信使用 HTTP 协议完成从客户端到服务器端的工作流程。客户端(Client)是对通过发送请求获取服务器资源的 Web 浏览器等的统称。
img_11_1.png

HTTP 协议发展历程

HTTP/0.9 诞生于 1990 年,正式版本 HTTP/1.1 在 1996 年 5月发布,当前使用非常广泛的 HTTP/1.1 版本发布于 1997 年 1月。未来版本 HTTP/2.0 早在 2013 年 8月就已经推出,但由于 HTTP/1.1 的高度普及导致 2.0 版本的升级非常缓慢。

HTTP/2.0 性能提升巨大,安全性方面通过 https:// 保障,而 http:// 则保留于 HTTP/1.1 版本

  • 多路复用流:通过单一的 TCP 连接,可以无限制处理多个 HTTP 请求。所有请求的处理都在一条 TCP 连接上完成,提高 TCP 的处理效率
  • 流量控制(赋予请求优先级):在发送多个请求时,解决因宽带低而导致响应变慢的问题
  • 压缩 HTTP 首部:压缩 HTTP 请求和响应的首部,减少通信产生的数据包数量和发送的字节数

网络基础 TCP/IP

计算机与网络设备要相互通信,双方就必须基于相同的方法。比如,如何探测到通信目标、由哪一边先发起通信、使用哪种语言进行通信、怎样结束通信等规则都需要事先确定。不同的硬件、操作系统之间的通信,所有的这一切都需要一种规则。

协议(protocol)是网络通信过程中双方都遵守使用的规则的统称。TCP/IP 是互联网相关的各类协议族的总称,HTTP 属于 TCP/IP 协议族内部的一个子集。

image.png

TCP/IP 的分层管理

TCP/IP 协议族按层次分别分为以下 4 层

  • 应用层:决定了向用户提供应用服务时通信的活动。HTTP 协议就属于应用层。

TCP/IP 协议族预存了各类通用的应用服务。比如,FTP(文件传输协议) 和 DNS(域名系统) 服务;

  • 传输层:传输层对上层应用层,提供处于网络连接中的两台计算机之间的数据传输
    • TCP:传输控制协议
    • UDP:用户数据报协议
  • 网络层:用来处理在网络上流动的数据包

数据包是网络传输的最小数据单位。该层规定了通过怎样的路径(传输路线)到达对方计算机,并把数据包传送给对方

  • 数据链路层:用来处理网络的硬件部分

数据链路层包括控制操作系统、硬件的设备驱动、网卡及光纤等物理可见部分。一切硬件上的范畴均在链路层的作用范围内。

TCP/IP 分层规划了各层之间的接口,每个层次内部可以自由设计改动。比如某一个地方需要改变设计时,只需把变动的层替换掉即可。而且分层之后,各层的职责也非常清晰。处于应用层上的应用可以只考虑分派给自己的任务,而不需要弄清对方在地球上的哪个地方、对方的传输路线是怎样的、是否能确保传输送达等问题。

TCP/IP 通信传输流

TCP/IP 协议族按照分层顺序与对方进行通信,发送端从应用层往下走,接收端则从应用层往上走。

发送端在层与层之间传输数据时,每经过一层是必定会被打上一个该层所属的首部信息。反之,接收端在层与层传输数据时,每经过一层时会把对应的首部信息移除。这种把数据信息包装起来的做法称为封装

image.png image.png

IP 协议、TCP 协议和 DNS 服务间的关系

负责传输的 IP 协议

按照层次分,IP 网络协议位于网络层,提供路由中转服务。

IP 间使用 ARP 协议凭借 MAC 地址进行通信

在网络上,通信的双方一般不在同一局域网中,通常是经过多台计算机和网络设备中转才能连接到对方。而在进行中转时,使用 ARP 协议解析通信方的 IP 地址反查出对应的 MAC 地址搜索出下一站中转设备。

在数据包到达通信目标前的中转过程中,计算机和路由器等网络设备只能获悉很粗略的传输路线,这种机制称为路由选择(routing)。这个过程类似快递公司的送货过程,想要寄东西的人,只需要将自己的货物送到集散中心,就可以知道快递公司是否肯收件发货,该快递公司的集散中心检查货物的送达地址,明确下一站该送往哪个区域的集散中心。中间层层流转,直到目标区域的集散中心能将货物送到指定地址为止。

img_21_1.png

IP 和 IP 地址

  • IP 是 Internet Protocol 的缩写,它的作用是把数据包传送给对方。按照层次分,IP 网络协议位于网络层,几乎所有的网络系统都会用到 IP 协议。
  • IP 地址指互联网中某个节点被分配到的地址,MAC 地址指网卡所属的固定地址。IP 地址可以和 MAC 地址进行配对。IP 地址可变换,但 MAC 地址基本不会改变

    IP 和 IP地址不可混淆,IP 是一种协议的简称而 IP 地址则像指示牌

确保可靠性的 TCP 协议

按照层次分,TCP 位于传输层提供字节流服务。为了方便传输,将大块数据分割成以报文段(segment)为单位的数据包进行管理,这种方式称为字节流服务。

三次握手保证准确性

为了准确无误的将数据送达目标处,TCP 协议采用了三次握手策略。用 TCP 协议把数据包送出去后,TCP 不会对传送后的情况置之不理,它一定会向对方确认是否成功送达。握手过程中使用了 TCP 的标志:SYN(synchronize) 和 ACK(acknowledgement)。

  1. 发送端首先发送一个带 SYN 标志的数据包给对方
  2. 接收端收到后,回传一个带有 SYN/ACK 标志的数据包以表示传达确认信息
  3. 发送端再回传一个带 ACK 标志的数据包代表“握手”结束。如果在握手的过程中某个阶段莫名中断,TCP 协议会再次以相同的顺序发送相同的数据包

    为什么要三次握手?

  • 第一次握手,发送端发送数据包正常

  • 第二次握手,接收端接收与发送数据包均正常

  • 第三次握手,发送段接受数据包正常

img_22_1.png

四次挥手

数据传输完毕后,双方都可释放连接。最开始的时候,客户端和服务器都是处于 ESTABLISHED 状态,然后客户端主动关闭,服务器被动关闭

  1. 客户端进程发出连接释放报文,并且停止发送数据。释放数据报文首部,FIN=1,其序列号为seq=u(等于前面已经传送过来的数据的最后一个字节的序号加1),此时,客户端进入FIN-WAIT-1(终止等待1)状态。 TCP规定,FIN报文段即使不携带数据,也要消耗一个序号。
  2. 服务器收到连接释放报文,发出确认报文,ACK=1,ack=u+1,并且带上自己的序列号seq=v,此时,服务端就进入了CLOSE-WAIT(关闭等待)状态。TCP服务器通知高层的应用进程,客户端向服务器的方向就释放了,这时候处于半关闭状态,即客户端已经没有数据要发送了,但是服务器若发送数据,客户端依然要接受。这个状态还要持续一段时间,也就是整个CLOSE-WAIT状态持续的时间。
  3. 客户端收到服务器的确认请求后,此时,客户端就进入FIN-WAIT-2(终止等待2)状态,等待服务器发送连接释放报文(在这之前还需要接受服务器发送的最后的数据)。
  4. 服务器将最后的数据发送完毕后,就向客户端发送连接释放报文,FIN=1,ack=u+1,由于在半关闭状态,服务器很可能又发送了一些数据,假定此时的序列号为seq=w,此时,服务器就进入了LAST-ACK(最后确认)状态,等待客户端的确认。
  5. 客户端收到服务器的连接释放报文后,必须发出确认,ACK=1,ack=w+1,而自己的序列号是seq=u+1,此时,客户端就进入了TIME-WAIT(时间等待)状态。注意此时TCP连接还没有释放,必须经过2∗ *∗MSL(最长报文段寿命)的时间后,当客户端撤销相应的TCB后,才进入CLOSED状态。
  6. 服务器只要收到了客户端发出的确认,立即进入CLOSED状态。同样,撤销TCB后,就结束了这次的TCP连接。可以看到,服务器结束TCP连接的时间要比客户端早一些

tcp-4.gif

为什么要四次挥手?

任何一方都可以在数据传送结束后发出连接释放的通知,待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候,则发出连接释放通知,对方确认后就完全关闭了TCP连接

负责域名解析的 DNS 服务

DNS 服务和 HTTP 协议都位于应用层,它提供域名到 IP 地址之间的解析服务。DNS 协议提供通过域名查找 IP 地址,或逆向从 IP 地址反查域名的服务

计算机既可以被赋予 IP 地址,也可以被赋予主机名和域名。比如 www.baidu.com

用户通常使用主机名或域名来访问对方的计算机。因为与 IP 地址的 一组纯数字相比,用字母配合数字的表示形式来指定计算机名更符合人类的记忆习惯,但是让计算机去理解名称就变得十分困难,计算机更擅长处理一长串数字。为了解决这个问题,DNS 服务应运而生。
img_23_1.png

浏览器中打开页面背后发生的事情

  1. 客户端浏览器向 DNS 服务请求域名指向的 IP 地址
  2. DNS 服务响应请求域名的 IP 地址
  3. 客户端使用 HTTP 协议生成对目标 Web 服务器的 HTTP 请求报文
  4. 客户端使用 TCP 协议将 HTTP 请求报文分隔成报文段传输给对方
  5. 传输过程中使用 IP 协议一边中转一边传输
  6. Web 服务器使用 TCP 协议重组接收到的报文段
  7. Web 服务器使用 HTTP 协议响应请求报文需要的资源
  8. Web 服务器再利用 TCP/IP 协议进行回传

img_24_1.png

URI 和 URL

URI 是在某一规则下标识出一个资源的字符串,规则可以是地址,也可以是号码。其中通过地址规则实现的 URI 称作 URL,所以 URL 是 URI 的一种实现,就像三角形包含等边三角形,等边三角形也属于三角形。如图,http://hack.jp 就是 URL。
img_25_1.png

绝对 URI、绝对 URL和相对 URL

img_27_1.png

  • 协议方案名:使用 http: 或 https: 等协议方案名获取访问资源时要指定协议类型。不区分字母大小写,最后附一个冒号(:)。 也可使用 data: 或 javascript: 这类指定数据或脚本程序的方案名。
  • 登录信息(认证): 指定用户名和密码作为从服务器端获取资源时必要的登录信息(身份 认证)。
  • 服务器地址:使用绝对 URI 必须指定待访问的服务器地址。地址可以是类似 hackr.jp 这种 DNS 可解析的名称,或是 192.168.1.1 这类 IPv4 地址 名,还可以是 [0:0:0:0:0:0:0:1] 这样用方括号括起来的 IPv6 地址名。
  • 服务器端口号:指定服务器连接的网络端口号。若用户省略则自动使用默认端口号。
    • http 协议默认 80 端口
    • https 协议默认 443 端口
    • ftp 协议默认 21 端口
    • ssh 协议默认 22 端口
    • telnet 协议默认 23 端口
    • pop3 协议默认 110 端口
    • smtp 协议默认 25 端口
  • 带层次的文件路径:指定服务器上的文件路径来定位特指的资源。这与 UNIX 系统的文件目录结构相似。
  • 查询字符串:针对已指定的文件路径内的资源,可以使用查询字符串传入任意参 数。
  • 片段标识符:使用片段标识符通常可标记出已获取资源中的子资源(文档内的某个位置)。