HTTP传输协议原理

目录

1 简介

1.1 简单的HTTP协议

1.2 主要特点

1.3 HTTP请求响应模型

2 工作原理与过程

2.1 工作原理

2.2 用户访问网站的过程？

2.3 HTTP协议栈中各层数据流   

3 请求

(1) 请求方法

(2) 请求的网址

(3) 请求头

(4) 请求体

4 响应

(1) 响应状态码

(2) 响应头

(3) 响应体

5 HTTP/1.1与HTTP/1.0的区别

6 HTTP各种长度限制 

1. URL长度限制

2. Post数据的长度限制

3. Cookie的长度限制

4. Html5 LocalStorage

---

1 简介

1.1 简单的HTTP协议

HTTP协议，全称HyperText Transfer Protocol，中文名为超文本传输协议，是互联网中最常用的一种网络协议。HTTP的重要应用之一是WWW服务。设计HTTP协议最初目的就是提供一种发布和接收HTML（一种页面标记语言）页面的方法（请求返回）。

HTTP协议是互联网上常用的通信协议之一。它有很多的应用，但最流行的就是用于Web浏览器和Web服务器之间的通信，即WWW应用或称Web应用。

WWW，全称World Wide Web，常称为Web，中文译为“万维网”。它是目前互联网上最受用户欢迎的信息服务形式。HTTP协议的WWW服务应用的默认端口为80（端口的概念），另外的一个加密的WWW服务应用https的默认端口为443，主要用于网银，支付等和钱相关的业务。当今，HTTP服务，WWW服务，Web服务三者的概念已经混淆了，都是指当下最常见的网站服务应用。

 HTTP是基于TCP协议之上的。在TCP/IP协议参考模型的各层对应的协议如下图,其中HTTP是应用层的协议。
 

1.2 主要特点

http1.0的主要特点:
简单快速：当客户端向服务器端发送请求时，只是简单的填写请求路径和请求方法即可，然后就可以通过浏览器或其他方式将该请求发送就行了 。
灵活： HTTP 协议允许客户端和服务器端传输任意类型任意格式的数据对象
无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接，采用这种方式可以节省传输时间。(当今多数服务器支持Keep-Alive功能，使用服务器支持长连接，解决无连接的问题)
无状态：无状态是指协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。即客户端发送HTTP请求后，服务器根据请求，会给我们发送数据，发送完后，不会记录信息。(使用 cookie 机制可以保持 session，解决无状态的问题)

http1.1的特点
a、默认持久连接节省通信量，只要客户端服务端任意一端没有明确提出断开TCP连接，就一直保持连接，可以发送多次HTTP请求 。
b、管线化，客户端可以同时发出多个HTTP请求，而不用一个个等待响应 。
c、断点续传，就是可以将一个大数据，分段传输，客户端可以慢慢显示。

http2.0的特点
a、HTTP/2采用二进制格式而非文本格式
b、HTTP/2是完全多路复用的，而非有序并阻塞的——只需一个HTTP连接就可以实现多个请求响应
c、使用报头压缩，HTTP/2降低了开销
d、HTTP/2让服务器可以将响应主动“推送”到客户端缓存中

1.3 HTTP请求响应模型

       HTTP由请求和响应构成，是一个标准的客户端服务器模型（B/S）。HTTP协议永远都是客户端发起请求，服务器回送响应。见下图:

    

       HTTP是一个无状态的协议。无状态是指客户机（Web浏览器）和服务器之间不需要建立持久的连接，这意味着当一个客户端向服务器端发出请求，然后服务器返回响应(response)，连接就被关闭了，在服务器端不保留连接的有关信息.HTTP遵循请求(Request)/应答(Response)模型。客户机（浏览器）向服务器发送请求，服务器处理请求并返回适当的应答。所有HTTP连接都被构造成一套请求和应答。

2 工作原理与过程

2.1 工作原理

在http传输的过程中，被称为客户端的请求者向服务器请求一个文件。
最基本的过程是:
1 客户端连接一个主机；
2 服务器接收连接,
3 客户端请求一个文件,
4 服务器发送一个应答.

一次HTTP操作称为一个事务，其工作整个过程如下：

     1 ) 、地址解析，

     如用客户端浏览器请求这个页面：http://localhost.com:8080/index.htm

     从中分解出协议名、主机名、端口、对象路径等部分，对于我们的这个地址，解析得到的结果如下：
     协议名：http
     主机名：localhost.com
     端口：8080
     对象路径：/index.htm

      在这一步，需要域名系统DNS解析域名localhost.com,得主机的IP地址。

    2）封装HTTP请求数据包

     把以上部分结合本机自己的信息，封装成一个HTTP请求数据包

     3）封装成TCP包，建立TCP连接（TCP的三次握手）

       在HTTP工作开始之前，客户机（Web浏览器）首先要通过网络与服务器建立连接，该连接是通过TCP来完成的，该协议与IP协议共同构建Internet，即著名的TCP/IP协议族，因此Internet又被称作是TCP/IP网络。HTTP是比TCP更高层次的应用层协议，根据规则，只有低层协议建立之后才能，才能进行更层协议的连接，因此，首先要建立TCP连接，一般TCP连接的端口号是80。这里是8080端口

     4）客户机发送请求命令

       建立连接后，客户机发送一个请求给服务器，请求方式的格式为：统一资源标识符（URI）、协议版本号，后边是MIME信息包括请求修饰符、客户机信息和可内容。

这里顺便说明个人理解

URI：  统一资源标识符，用来唯一的标识一个资源，是一种语义上的抽象概念。
URL ：统一资源定位符，它是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何访问到这个资源

URI是以一种抽象的，高层次概念定义统一资源标识，标记了一个网络资源，而URL则是具体的资源标识的方式。

简单比喻 - URI唯一标识一个人（例如身份证）， URL定义了如何访问到这个人（例如家庭地址）

     5）服务器响应

     服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。

        实体消息是服务器向浏览器发送头信息后，它会发送一个空白行来表示头信息的发送到此为结束，接着，它就以Content-Type应答头信息所描述的格式发送用户所请求的实际数据

     6）服务器关闭TCP连接

     一般情况下，一旦Web服务器向浏览器发送了请求数据，它就要关闭TCP连接，然后如果浏览器或者服务器在其头信息加入了这行代码

    Connection:keep-alive

   TCP连接在发送后将仍然保持打开状态，于是，浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间，还节约了网络带宽

2.2 用户访问网站的过程？

1. 利用DNS协议进行域名解析

第一步：客户端用户从浏览器里输入www.baidu.com网站地址，回车后，系统首先会查找系统本地的DNS缓存及hosts文件信息，查找是否存在www.baidu.com域名对应的IP解析记录，如果有就直接获取IP地址，然后去访问这个IP地址对应域名www.baidu.com的服务器，一般第一次请求时，DNS缓存是没有解析记录的，而hosts多在内部临时测试时使用。

第二步：如果客户端本地DNS缓存及hosts文件没有www.baidu.com域名对应的解析记录，那么，系统会把浏览器的解析请求发送给客户端本地设置的DNS服务器地址（通常称此DNS为LDNS或首选DNS服务器，即Local DNS）解析，如果LDNS服务器的本地缓存有对应的解析记录就会直接返回IP地址给客户端，如果没有，则LDNS会负责继续请求其他的DNS服务器。

第三步：LDNS会从DNS系统的根域（.）开始请求www.baidu.com域名的解析，针对各个层级的DNS服务器系统进行一系列的查找，最终会查找到baidu.com域名对应的授权DNS服务器，而这个授权DNS服务器正是企业购买域名时用于管理域名解析的服务器，这个授权服务器会有www.baidu.com对应的IP解析记录，如果此时没有，就表示企业的域名管理人员没有为www.baidu.com域名做解析设置，即网站还没架设好

第四步：baidu.com域名的授权DNS服务器会把www.baidu.com对应的最终IP解析记录发给LDNS。

第五步：LDNS把收到的来自授权DNS服务器www.baidu.com对应的IP解析记录（A记录）缓存到本地，再发给客户端，以便下一次更快的返回相同解析请求的记录，这些缓存记录在指定的时间（DNS TTL值控制）内不会过期。

第六步：客户端浏览器获取到了www.etiantian.org的对应IP地址的解析记录，会先缓存到本地，接下来，浏览器会请求获得的IP地址对应的网站服务器

2. 建立tcp协议三次握手过程

3. 客户端发出访问网站相应页面请求（发出http协议请求报文）

4. 系统架构部署情况

5. 服务端发出响应访问页面的请求信息（发出http协议响应报文）

6. 断开tcp协议四次挥手过程

提示：

上述仅仅是客户端用户第一次访问网站的基本过程，连续访问后，系统本地和LDNS层级都会有缓存记录，再访问时流程就会有些变化，会直接取本地缓存记录，这样访问过程就很快了。在上述整个访问流程里，包含了DNS的解析流程以及HTTP协议的通信原理等重要的技术点。

2.3 HTTP协议栈中各层数据流   

首先我们看看客户端请求的时候，数据在各层协议的数据组织如下图：

         

            而服务器解析客户机请求就是反向操作的过程，如下图：

           
              客户机发起一次请求的时候：

       客户机会将请求封装成http数据包-->封装成Tcp数据包-->封装成Ip数据包--->封装成数据帧--->硬件将帧数据转换成bit流（二进制数据）-->最后通过物理硬件（网卡芯片）发送到指定地点。

       服务器硬件首先收到bit流....... 然后转换成ip数据包。于是通过ip协议解析Ip数据包，然后又发现里面是tcp数据包，就通过tcp协议解析Tcp数据包，接着发现是http数据包通过http协议再解析http数据包得到数据。

3 请求

请求，由客户端向服务端发出，可以分为4部分内容：请求方法（Request Method）、请求的网址（Request URL）、请求头（Request Headers）、请求体（Request Body）。

 

(1) 请求方法

常见的请求方法有两种：GET和POST。

在浏览器中直接输入URL并回车，这便发起了一个GET请求，请求的参数会直接包含到URL里。例如，在百度中搜索Python，这就是一个GET请求，链接为https://www.baidu.com/s?wd=Python，其中URL中包含了请求的参数信息，这里参数wd表示要搜寻的关键字。POST请求大多在表单提交时发起。比如，对于一个登录表单，输入用户名和密码后，点击“登录”按钮，这通常会发起一个POST请求，其数据通常以表单的形式传输，而不会体现在URL中。

GET和POST请求方法有如下区别。

• GET请求中的参数包含在URL里面，数据可以在URL中看到，而POST请求的URL不会包含这些数据，数据都是通过表单形式传输的，会包含在请求体中。
• GET请求提交的数据最多只有1024字节，而POST方式没有限制。

一般来说，登录时，需要提交用户名和密码，其中包含了敏感信息，使用GET方式请求的话，密码就会暴露在URL里面，造成密码泄露，所以这里最好以POST方式发送。上传文件时，由于文件内容比较大，也会选用POST方式。

1、get重点在从服务器上获取资源，post重点在向服务器发送数据；

2、get传输数据是通过URL请求，以field（字段）= value的形式，置于URL后，并用”?”连接，多个请求数据间用”&”连接，如http://127.0.0.1/Test/login.action?name=admin&password=admin，这个过程用户是可见的；
post传输数据通过Http的post机制，将字段与对应值封存在请求实体中发送给服务器，这个过程对用户是不可见的；

3、Get传输的数据量小，因为受URL长度限制，但效率较高；
Post可以传输大量数据，所以上传文件时只能用Post方式；

4、get是不安全的，因为URL是可见的，可能会泄露私密信息，如密码等；
post较get安全性较高；

我们平常遇到的绝大部分请求都是GET或POST请求，另外还有一些请求方法，如GET、HEAD、POST、PUT、DELETE、OPTIONS、CONNECT、TRACE等，我们简单将其总结为表2-1。

表2-1 其他请求方法

本表参考：http://www.runoob.com/http/http-methods.html。

(2) 请求的网址

请求的网址，即统一资源定位符URL，它可以唯一确定我们想请求的资源。

(3) 请求头

请求头，用来说明服务器要使用的附加信息，比较重要的信息有Cookie、Referer、User-Agent等。下面简要说明一些常用的头信息。

• Accept：请求报头域，用于指定客户端可接受哪些类型的信息。
• Accept-Language：指定客户端可接受的语言类型。
• Accept-Encoding：指定客户端可接受的内容编码。
• Host：用于指定请求资源的主机IP和端口号，其内容为请求URL的原始服务器或网关的位置。从HTTP 1.1版本开始，请求必须包含此内容。
• Cookie：也常用复数形式 Cookies，这是网站为了辨别用户进行会话跟踪而存储在用户本地的数据。它的主要功能是维持当前访问会话。例如，我们输入用户名和密码成功登录某个网站后，服务器会用会话保存登录状态信息，后面我们每次刷新或请求该站点的其他页面时，会发现都是登录状态，这就是Cookies的功劳。Cookies里有信息标识了我们所对应的服务器的会话，每次浏览器在请求该站点的页面时，都会在请求头中加上Cookies并将其发送给服务器，服务器通过Cookies识别出是我们自己，并且查出当前状态是登录状态，所以返回结果就是登录之后才能看到的网页内容。
• Referer：此内容用来标识这个请求是从哪个页面发过来的，服务器可以拿到这一信息并做相应的处理，如作来源统计、防盗链处理等。
• User-Agent：简称UA，它是一个特殊的字符串头，可以使服务器识别客户使用的操作系统及版本、浏览器及版本等信息。在做爬虫时加上此信息，可以伪装为浏览器；如果不加，很可能会被识别出为爬虫。
• Content-Type：也叫互联网媒体类型（Internet Media Type）或者MIME类型，在HTTP协议消息头中，它用来表示具体请求中的媒体类型信息。例如，text/html代表HTML格式，image/gif代表GIF图片，application/json代表JSON类型，更多对应关系可以查看此对照表：http://tool.oschina.net/commons。

因此，请求头是请求的重要组成部分，在写爬虫时，大部分情况下都需要设定请求头。

(4) 请求体

请求体一般承载的内容是POST请求中的表单数据，而对于GET请求，请求体则为空。

例如，这里我登录GitHub时捕获到的请求和响应如图2-7所示。

 详细信息

登录之前，我们填写了用户名和密码信息，提交时这些内容就会以表单数据的形式提交给服务器，此时需要注意Request Headers中指定Content-Type为application/x-www-form-urlencoded。只有设置Content-Type为application/x-www-form-urlencoded，才会以表单数据的形式提交。另外，我们也可以将Content-Type设置为application/json来提交JSON数据，或者设置为multipart/form-data来上传文件。

表2-2 Content-Type和POST提交数据方式的关系

在爬虫中，如果要构造POST请求，需要使用正确的Content-Type，并了解各种请求库的各个参数设置时使用的是哪种Content-Type，不然可能会导致POST提交后无法正常响应。

4 响应

响应，由服务端返回给客户端，可以分为三部分：响应状态码（Response Status Code）、响应头（Response Headers）和响应体（Response Body）。

查看请求报文与响应报文详细结构信息方法：（2种方法）

1. curl -v www.baidu.com    --- 利用curl命令进行网站访问

                       -v      --- 详细显示请求报文结构和响应报文结构信息

2. wget --debug www.baidu.com

(1) 响应状态码

响应状态码表示服务器的响应状态，如200代表服务器正常响应，404代表页面未找到，500代表服务器内部发生错误。在爬虫中，我们可以根据状态码来判断服务器响应状态，如状态码为200，则证明成功返回数据，再进行进一步的处理，否则直接忽略。表2-3列出了常见的错误代码及错误原因。

表2-3 常见的错误代码及错误原因

(2) 响应头

响应头包含了服务器对请求的应答信息，如Content-Type、Server、Set-Cookie等。下面简要说明一些常用的头信息。

• Date：标识响应产生的时间。
• Last-Modified：指定资源的最后修改时间。
• Content-Encoding：指定响应内容的编码。
• Server：包含服务器的信息，比如名称、版本号等。
• Content-Type：文档类型，指定返回的数据类型是什么，如text/html代表返回HTML文档，application/x-javascript则代表返回JavaScript文件，image/jpeg则代表返回图片。
• Set-Cookie：设置Cookies。响应头中的Set-Cookie告诉浏览器需要将此内容放在Cookies中，下次请求携带Cookies请求。
• Expires：指定响应的过期时间，可以使代理服务器或浏览器将加载的内容更新到缓存中。如果再次访问时，就可以直接从缓存中加载，降低服务器负载，缩短加载时间。

(3) 响应体

最重要的当属响应体的内容了。响应的正文数据都在响应体中，比如请求网页时，它的响应体就是网页的HTML代码；请求一张图片时，它的响应体就是图片的二进制数据。我们做爬虫请求网页后，要解析的内容就是响应体，如图2-8所示。

图2-8 响应体内容

在浏览器开发者工具中点击Preview，就可以看到网页的源代码，也就是响应体的内容，它是解析的目标。

5 HTTP/1.1与HTTP/1.0的区别

HTTP协议的初始版本中， 每进行一次 HTTP通信就要断开一次TCP连接，因为都是些容量很小的文本传输， 所以即使这样也没有多大问题。 可随着HTTP的普及， 文档中包含大量图片的情况多了起来。为解决上述TCP连接的问题， HTTP/1.1和一部分的 HTTP/1.0 想出了持久连接（HTTP Persistent Connections， 也称为 HTTPkeep-alive 或HTTP connection reuse）的方法。 持久连接的特点是， 只要任意一端没有明确提出断开连接， 则保持TCP连接状态。持久连接的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销， 减轻了服务器端的负载。 另外， 减少开销的那部分时间， 使HTTP请求和响应能够更早地结束， 这样 Web 页面的显示速度也就相应提高了。
传统无连接：

现在持久连接：

持久连接使得多数请求以管线化（pipelining）方式发送成为可能。从前发送请求后需等待并收到响应，才能发送下一个请求。 管线化技术出现后， 不用等待响应亦可直接发送下一个请求。这样就能够做到同时并行发送多个请求， 而不需要一个接一个地等待响应了。

HTTP1.0最早在网页中使用是在1996年，那个时候只是使用一些较为简单的网页上和网络请求上，而HTTP1.1则在1999年才开始广泛应用于现在的各大浏览器网络请求中，同时HTTP1.1也是当前使用最为广泛的HTTP协议。 主要区别主要体现在：

1. 缓存处理，在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。

2. 带宽优化及网络连接的使用，HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。

3. 错误通知的管理，在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。

4. Host头处理，在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。

5. 长连接，HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。

6 HTTP各种长度限制 

1. URL长度限制

在Http1.1协议中并没有提出针对URL的长度进行限制，RFC协议里面是这样描述的，HTTP协议并不对URI的长度做任何的限制，服务器端必须能够处理任何它们所提供服务多能接受的URI，并且能够处理无限长度的URI,如果服务器不能处理过长的URI,那么应该返回414状态码。

虽然Http协议规定了，但是Web服务器和浏览器对URI都有自己的长度限制。

服务器的限制:我接触的最多的服务器类型就是Nginx和Tomcat,对于url的长度限制，它们都是通过控制http请求头的长度来进行限制的，nginx的配置参数为large_client_header_buffers，tomcat的请求配置参数为maxHttpHeaderSize,都是可以自己去进行设置。

浏览器的限制:每种浏览器也会对url的长度有所限制，下面是几种常见浏览器的url长度限制:(单位:字符)

IE : 2803

Firefox:65536

Chrome:8182

Safari:80000

Opera:190000

对于get请求，在url的长度限制范围之内，请求的参数个数没有限制。

2. Post数据的长度限制

Post数据的长度限制与url长度限制类似，也是在Http协议中没有规定长度限制,长度限制可以在服务器端配置最大http请求头长度的方式来实现。

3. Cookie的长度限制

Cookie的长度限制分这么几个方面来总结。

(1) 浏览器所允许的每个域下的最大cookie数目,没有去自己测试，从网上找到的资料大概是这么个情况

IE :原先为20个，后来升级为50个

Firefox: 50个

Opera:30个

Chrome:180个

Safari:无限制

当Cookie数超过限制数时浏览器的行为：IE和Opera会采用LRU算法将老的不常使用的Cookie清除掉，Firefox的行为是随机踢出某些Cookie的值。当然无论怎样的策略，还是尽量不要让Cookie数目超过浏览器所允许的范围。

(2) 浏览器所允许的每个Cookie的最大长度

Firefox和Safari:4079字节

Opera:4096字节

IE:4095字节

(3) 服务器中Http请求头长度的限制。Cookie会被附在每次http请求头中传递给服务器，因此还会受到服务器请求头长度的影响。

4. Html5 LocalStorage

Html5提供了本地存储机制来供Web应用在客户端存储数据，尽管这个并不属于Http协议的一部分，但是随着Html5的流行，我们可能需要越来越多使用LocalStorage,甚至当它普及的时候跟它打交道就会同今天我们跟Cookie打交道一样多。

对于LocalStorage的长度限制，同Cookie的限制类似，也是浏览器针对域来限制,只不过cookie限制的是个数，LocalStorage限制的是长度:

Firefox\Chrome\Opera都是允许每个域的最大长度为5MB

但是这次IE比较大方，允许的最大长度是10MB