爬虫开发技术基础教程之HTTP基础.

时间  2019-12-06
标签 爬虫 开发 技术 基础 教程 http 栏目 网络爬虫 繁體版
原文   原文链接

HTTP简介

HTTP协议是创建在TCP之上的无状态应用层协议，用于收发网络资源（一般是HTML页面），默认使用80端口。php

HTTP报文

请求报文

HTTP 协议是以 ASCII 码传输，创建在 TCP/IP 协议之上的应用层规范。规范把 HTTP 请求分为三个部分：状态行、请求头、消息主体。相似于下面这样：html

<method> <request-URL> <version>
<headers>

<entity-body>

HTTP定义了与服务器交互的不一样方法，最基本的方法有4种，分别是GET，POST，PUT，DELETE。URL全称是资源描述符，咱们能够这样认为：一个URL地址，它用于描述一个网络上的资源，而 HTTP 中的GET，POST，PUT，DELETE就对应着对这个资源的查，增，改，删4个操做。python

  1. GET用于信息获取，并且应该是安全的 和 幂等的。git

所谓安全的意味着该操做用于获取信息而非修改信息。换句话说，GET 请求通常不该产生反作用。就是说，它仅仅是获取资源信息，就像数据库查询同样，不会修改，增长数据，不会影响资源的状态。github

幂等的意味着对同一URL的多个请求应该返回一样的结果。chrome

GET请求提交的参数在URL里，为 ? 后面的部分，以下面的示例，其中参数为sex和name，其值分别为 man 和 Professional。数据库

GET请求报文示例：编程

GET /books/?sex=man&name=Professional HTTP/1.1
 Host: www.example.com
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
 Gecko/20050225 Firefox/1.0.1
 Connection: Keep-Alive

  1. POST表示可能修改变服务器上的资源的请求。json

    POST / HTTP/1.1
 Host: www.example.com
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
 Gecko/20050225 Firefox/1.0.1
 Content-Type: application/x-www-form-urlencoded
 Content-Length: 40
 Connection: Keep-Alive

 sex=man&name=Professional

  2. 注意:后端

    • GET 可提交的数据量受到URL长度的限制，HTTP 协议规范没有对 URL 长度进行限制。这个限制是特定的浏览器及服务器对它的限制

    • 理论上讲，POST 是没有大小限制的，HTTP 协议规范也没有进行大小限制，出于安全考虑，服务器软件在实现时会作必定限制

    • 参考上面的报文示例，能够发现 GET 和 POST 数据内容是如出一辙的，只是位置不一样，一个在URL里，一个在 HTTP 包的包体里

    • GET 方法访问的地址一般复制到浏览器地址栏，能够直接访问结果，而POST方法必须借助工具（如 POSTman 或者 CURL命令等）来进行访问。

POST 提交数据的方式

HTTP 协议中规定 POST 提交的数据必须在 body 部分中，可是协议中没有规定数据使用哪一种编码方式或者数据格式。实际上，开发者彻底能够本身决定消息主体的格式，只要最后发送的 HTTP 请求知足上面的格式就能够。

可是，数据发送出去，还要服务端解析成功才有意义。通常服务端语言如 php、python 等，以及它们的 framework，都内置了自动解析常见数据格式的功能。服务端一般是根据请求头（headers）中的 Content-Type 字段来获知请求中的消息主体是用何种方式编码，再对主体进行解析。因此说到 POST 提交数据方案，包含了 Content-Type 和消息主体编码方式两部分。下面就正式开始介绍它们：

  • application/x-www-form-urlencoded

这是最多见的 POST 数据提交方式。浏览器的原生 <form> 表单，若是不设置 enctype 属性，那么最终就会以 application/x-www-form-urlencoded 方式提交数据。上个小节当中的例子即是使用了这种提交方式。能够看到 body 当中的内容和 GET 请求是彻底相同的。

  • multipart/form-data

这又是一个常见的 POST 数据提交的方式。咱们使用表单上传文件时，必须让 <form> 表单的 enctype 等于 multipart/form-data。直接来看一个请求示例：

POST http://www.example.com HTTP/1.1
Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryrGKCBY7qhFd3TrwA

------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="text"

title
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="file"; filename="chrome.png"
Content-Type: image/png

PNG ... content of chrome.png ...
------WebKitFormBoundaryrGKCBY7qhFd3TrwA--

这个例子稍微复杂点。首先生成了一个 boundary 用于分割不一样的字段，为了不与正文内容重复，boundary 很长很复杂。而后 Content-Type 里指明了数据是以 multipart/form-data 来编码，本次请求的 boundary 是什么内容。消息主体里按照字段个数又分为多个结构相似的部分，每部分都是以 --boundary 开始，紧接着是内容描述信息，而后是回车，最后是字段具体内容（文本或二进制）。若是传输的是文件，还要包含文件名和文件类型信息。消息主体最后以 --boundary-- 标示结束。关于 multipart/form-data 的详细定义，请前往 RFC1867 查看（或者相对友好一点的 MDN 文档）。

这种方式通常用来上传文件，各大服务端语言对它也有着良好的支持。

上面提到的这两种 POST 数据的方式，都是浏览器原生支持的，并且现阶段标准中原生 <form> 表单也只支持这两种方式（经过 <form> 元素的 enctype 属性指定，默认为 application/x-www-form-urlencoded。其实 enctype 还支持 text/plain，不过用得很是少）。

随着愈来愈多的 Web 站点，尤为是 WebApp，所有使用 Ajax 进行数据交互以后，咱们彻底能够定义新的数据提交方式，例如 application/json，text/xml，乃至 application/x-protobuf 这种二进制格式，只要服务器能够根据 Content-Type 和 Content-Encoding 正确地解析出请求，都是没有问题的。

条件 GET

HTTP 条件 GET 是 HTTP 协议为了减小没必要要的带宽浪费，提出的一种方案。详见 RFC2616 。

  1. HTTP 条件 GET 使用的时机？

客户端以前已经访问过某网站，并打算再次访问该网站。

  1. HTTP 条件 GET 使用的方法？

客户端向服务器发送一个包询问是否在上一次访问网站的时间后是否更改了页面，若是服务器没有更新，显然不须要把整个网页传给客户端，客户端只要使用本地缓存便可，若是服务器对照客户端给出的时间已经更新了客户端请求的网页，则发送这个更新了的网页给用户。

下面是一个具体的发送接受报文示例：

客户端发送请求：

GET / HTTP/1.1  
 Host: www.sina.com.cn:80  
 If-Modified-Since:Thu, 4 Feb 2010 20:39:13 GMT  
 Connection: Close

第一次请求时，服务器端返回请求数据，以后的请求，服务器根据请求中的 If-Modified-Since 字段判断响应文件没有更新，若是没有更新，服务器返回一个 304 Not Modified响应，告诉浏览器请求的资源在浏览器上没有更新，可使用已缓存的上次获取的文件。

HTTP/1.0 304 Not Modified  
 Date: Thu, 04 Feb 2010 12:38:41 GMT  
 Content-Type: text/html  
 Expires: Thu, 04 Feb 2010 12:39:41 GMT  
 Last-Modified: Thu, 04 Feb 2010 12:29:04 GMT  
 Age: 28  
 X-Cache: HIT from sy32-21.sina.com.cn  
 Connection: close

若是服务器端资源已经更新的话，就返回正常的响应。

响应报文

HTTP 响应与 HTTP 请求类似，HTTP响应也由3个部分构成，分别是：

  • 状态行

  • 响应头(Response Header)

  • 响应正文

状态行由协议版本、数字形式的状态代码、及相应的状态描述，各元素之间以空格分隔。

常见的状态码有以下几种：

  • 200 OK 客户端请求成功

  • 301 Moved Permanently 请求永久重定向

  • 302 Moved Temporarily 请求临时重定向

  • 304 Not Modified 文件未修改，能够直接使用缓存的文件。

  • 400 Bad Request 因为客户端请求有语法错误，不能被服务器所理解。

  • 401 Unauthorized 请求未经受权。这个状态代码必须和WWW-Authenticate报头域一块儿使用

  • 403 Forbidden 服务器收到请求，可是拒绝提供服务。服务器一般会在响应正文中给出不提供服务的缘由

  • 404 Not Found 请求的资源不存在，例如，输入了错误的URL

  • 500 Internal Server Error 服务器发生不可预期的错误，致使没法完成客户端的请求。

  • 503 Service Unavailable 服务器当前不可以处理客户端的请求，在一段时间以后，服务器可能会恢复正常。

下面是一个HTTP响应的例子：

HTTP/1.1 200 OK

Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112

<html>...

RESTful API

随着开发技术的发展，愈来愈多的复杂功能被放置到了网站上，网站能够被理解为下载到浏览器里执行的软件，而这个网站与后端系统有频繁和复杂的通讯；同时，随着移动互联网的兴起，开发人员倾向于APP和网站使用统一的通讯接口，从而减少开发和维护的工做量。

RESTful架构便是目前最流行的一种互联网软件架构。它结构清晰、符合标准、易于理解、扩展方便，正获得愈来愈多网站的采用。（REST 是 Representational State Transfer 的缩写）

  1. 资源（Resources）

REST的名称"表现层状态转化"中，省略了主语。"表现层"其实指的是"资源"（Resources）的"表现层"。

所谓"资源"，就是网络上的一个实体，或者说是网络上的一个具体信息。它能够是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。你能够用一个URI（统一资源定位符）指向它，每种资源对应一个特定的URI。要获取这个资源，访问它的URI就能够，所以URI就成了每个资源的地址或独一无二的识别符。

所谓"上网"，就是与互联网上一系列的"资源"互动，调用它的URI。

  1. 表现层（Representation）

"资源"是一种信息实体，它能够有多种外在表现形式。咱们把"资源"具体呈现出来的形式，叫作它的"表现层"（Representation）。

好比，文本能够用txt格式表现，也能够用HTML格式、XML格式、JSON格式表现，甚至能够采用二进制格式；图片能够用JPG格式表现，也能够用PNG格式表现。

URI只表明资源的实体，不表明它的形式。严格地说，有些网址最后的".html"后缀名是没必要要的，由于这个后缀名表示格式，属于"表现层"范畴，而URI应该只表明"资源"的位置。它的具体表现形式，应该在HTTP请求的头信息中用Accept和Content-Type字段指定，这两个字段才是对"表现层"的描述。

  1. 状态转化（State Transfer）

访问一个网站，就表明了客户端和服务器的一个互动过程。在这个过程当中，势必涉及到数据和状态的变化。

互联网通讯协议HTTP协议，是一个无状态协议。这意味着，全部的状态都保存在服务器端。所以，若是客户端想要操做服务器，必须经过某种手段，让服务器端发生"状态转化"（State Transfer）。而这种转化是创建在表现层之上的，因此就是"表现层状态转化"。

客户端用到的手段，只能是HTTP协议。具体来讲，就是HTTP协议里面，四个表示操做方式的动词：GET、POST、PUT、DELETE。它们分别对应四种基本操做：GET用来获取资源，POST用来新建资源（也能够用于更新资源），PUT用来更新资源，DELETE用来删除资源。

JSON

经过HTTP传输的文本数据一般是HTML、XML或者JSON格式。

JSON(JavaScript Object Notation) 是一种轻量级的数据交换格式。 易于人阅读和编写。同时也易于机器解析和生成。在API的设计中使用尤其普遍。

JSON建构于两种结构：

“名称/值”对的集合（A collection of name/value pairs）。不一样的语言中，它被理解为对象（object），纪录（record），结构（struct），字典（dictionary），哈希表（hash table），有键列表（keyed list），或者关联数组 （associative array）。
值的有序列表（An ordered list of values）。在大部分语言中，它被理解为数组（array）。
这些都是常见的数据结构。事实上大部分现代计算机语言都以某种形式支持它们。这使得一种数据格式在一样基于这些结构的编程语言之间交换成为可能。

如，下面为京东的商品评论API及返回的JSON格式数据。能够直接复制该连接到浏览器地址栏打开，查看结果。

GET https://item.m.jd.com/ware/getDetailCommentList.json?wareId=4586850
{
  "wareDetailComment": {
    "allCnt": "303",
    "badCnt": "8",
    "canConsultFlag": "true",
    "code": "0",
    "commentInfoList": [
      {
        "commentData": "在京东买电子产品，从没失望过！好！速度超快！！昨天下午下单，今天11点就到了！牛！",
        "commentDate": "2017-03-15 15:47:52",
        "commentId": "10215478304",
        "commentScore": "5",
        "commentShareUrl": "http://share.m.jd.com/shareOrder/showSharePage.action?productId=4586850&commentId=817a736c-03b5-4bb2-add5-e9bfc9d63327",
        "commentType": "1",
        "guid": "817a736c-03b5-4bb2-add5-e9bfc9d63327",
        "orderDate": "2017-03-14 17:31:18",
        "pictureInfoList": [
          {
            "picURL": "http://img30.360buyimg.com/shaidan/s310x310_jfs/t3061/109/8735941683/32854/f3537a9d/58c8f1a6Nbb778993.jpg",
            "largePicURL": "http://img30.360buyimg.com/shaidan/s640x640_jfs/t3061/109/8735941683/32854/f3537a9d/58c8f1a6Nbb778993.jpg"
          },
          {
            "picURL": "http://img30.360buyimg.com/shaidan/s310x310_jfs/t4483/105/56391975/33044/caacfc3/58c8f1a7N3a2f3283.jpg",
            "largePicURL": "http://img30.360buyimg.com/shaidan/s640x640_jfs/t4483/105/56391975/33044/caacfc3/58c8f1a7N3a2f3283.jpg"
          },
          {
            "picURL": "http://img30.360buyimg.com/shaidan/s310x310_jfs/t4369/292/1941272094/42891/8ef49d7a/58c8f1a6N40c3a49a.jpg",
            "largePicURL": "http://img30.360buyimg.com/shaidan/s640x640_jfs/t4369/292/1941272094/42891/8ef49d7a/58c8f1a6N40c3a49a.jpg"
          }
        ],
        "plusAddress": "https://plus.m.jd.com/index",
        "plusAvailable": "0",
        "praiseCnt": "0",
        "replyCnt": "1",
        "userImgURL": "img30.360buyimg.com/mobile/s60x60_jfs/t493/15/557644423/10532/62d3112/5473e62aNdb4251d8.png",
        "userLevel": "2",
        "userNickName": "只***9",
        "wareAttribute": []
      },
      {
        "commentData": "在官网查过确实是正品，刚开始设置的时候出了点小插曲，不过很快就解决了，如今能够安心使用了！",
        "commentDate": "2017-03-15 14:08:39",
        "commentId": "10215168513",
        "commentScore": "5",
        "commentShareUrl": "http://share.m.jd.com/shareOrder/showSharePage.action?productId=4586850&commentId=6eac73a8-5ea3-47d2-8672-3402bd940c8b",
        "commentType": "1",
        "guid": "6eac73a8-5ea3-47d2-8672-3402bd940c8b",
        "orderDate": "2017-03-13 18:35:34",
        "pictureInfoList": [
          {
            "picURL": "http://img30.360buyimg.com/shaidan/s310x310_jfs/t3118/52/8822524381/41316/3ddbbeff/58c8da66Ne2e4f805.jpg",
            "largePicURL": "http://img30.360buyimg.com/shaidan/s640x640_jfs/t3118/52/8822524381/41316/3ddbbeff/58c8da66Ne2e4f805.jpg"
          }
        ],
        "plusAddress": "https://plus.m.jd.com/index",
        "plusAvailable": "0",
        "praiseCnt": "1",
        "replyCnt": "1",
        "userImgURL": "img30.360buyimg.com/mobile/s60x60_jfs/t493/15/557644423/10532/62d3112/5473e62aNdb4251d8.png",
        "userLevel": "1",
        "userNickName": "7***7",
        "wareAttribute": []
      },
      {
        "commentData": "图片是我苹果5拍的。昨天苹果6到手，下载完了所需app，内存足够的，还剩16.6g，运行速度还算快，可是估计想玩大游戏就扫兴了。总结吧：比较满意，可是建议你们仍是加点钱买6s长治久安。哈哈哈",
        "commentDate": "2017-03-16 12:42:34",
        "commentId": "10217967740",
        "commentScore": "5",
        "commentShareUrl": "http://share.m.jd.com/shareOrder/showSharePage.action?productId=4586850&commentId=bc436fcf-d814-4b01-a19b-572c597aa516",
        "commentType": "0",
        "guid": "bc436fcf-d814-4b01-a19b-572c597aa516",
        "orderDate": "2017-03-12 19:10:32",
        "pictureInfoList": null,
        "plusAddress": "https://plus.m.jd.com/index",
        "plusAvailable": "0",
        "praiseCnt": "0",
        "replyCnt": "0",
        "userImgURL": "img30.360buyimg.com/mobile/s60x60_jfs/t493/15/557644423/10532/62d3112/5473e62aNdb4251d8.png",
        "userLevel": "2",
        "userNickName": "q***0",
        "wareAttribute": []
      }
    ],
    "consultationCount": "13",
    "goodCnt": "290",
    "normalCnt": "5",
    "pictureCnt": "53",
    "showPicCnt": "53"
  }
}

关于JSON的详细介绍可参考：http://www.json.org/json-zh.html。

XMLHttpRequest

XMLHttpRequest是一个浏览器接口，使得Javascript能够进行HTTP(S)通讯。XMLHttpRequest 对象用于在后台与服务器交换数据，这样就能够

  • 在不从新加载页面的状况下更新网页

  • 在页面已加载后从服务器请求数据

  • 在页面已加载后从服务器接收数据

  • 在后台向服务器发送数据

会话跟踪

  1. 什么是会话？

客户端打开与服务器的链接发出请求到服务器响应客户端请求的全过程称之为会话。

  1. 什么是会话跟踪？

会话跟踪指的是对同一个用户对服务器的连续的请求和接受响应的监视。

  1. 为何须要会话跟踪？

浏览器与服务器之间的通讯是经过HTTP协议进行通讯的，而HTTP协议是”无状态”的协议，它不能保存客户的信息，即一次响应完成以后链接就断开了，下一次的请求须要从新链接，这样就须要判断是不是同一个用户，因此才有会话跟踪技术来实现这种要求。

  1. 会话跟踪经常使用的方法:

    1. URL重写

    URL(统一资源定位符)是Web上特定页面的地址，URL重写的技术就是在URL结尾添加一个附加数据以标识该会话,把会话ID经过URL的信息传递过去，以便在服务器端进行识别不一样的用户。

    1. 隐藏表单域

    将会话ID添加到HTML表单元素中提交到服务器，此表单元素并不在客户端显示

    1. Cookie

    Cookie是Web服务器发送给客户端的一小段信息，客户端请求时能够读取该信息发送到服务器端，进而进行用户的识别。对于客户端的每次请求，服务器都会将Cookie发送到客户端,在客户端能够进行保存,以便下次使用。

    客户端能够采用两种方式来保存这个Cookie对象，一种方式是保存在客户端内存中，称为临时Cookie，浏览器关闭后这个Cookie对象将消失。另一种方式是保存在客户机的磁盘上，称为永久Cookie。之后客户端只要访问该网站，就会将这个Cookie再次发送到服务器上，前提是这个Cookie在有效期内，这样就实现了对客户的跟踪。

    Cookie是能够被禁止的。

    1. Session:

    每个用户都有一个不一样的session，各个用户之间是不能共享的，是每一个用户所独享的，在session中能够存放信息。

    在服务器端会建立一个session对象，产生一个sessionID来标识这个session对象，而后将这个sessionID放入到Cookie中发送到客户端，下一次访问时，sessionID会发送到服务器，在服务器端进行识别不一样的用户。

    Session的实现依赖于Cookie，若是Cookie被禁用，那么session也将失效。

    Session是存储在服务器端，Cookie是存储在客户端，SessionID是Cookie里的一部分。

持久链接

咱们知道 HTTP 协议采用“请求-应答”模式，当使用普通模式，即非 Keep-Alive 模式时，每一个请求/应答客户和服务器都要新建一个链接，完成以后当即断开链接（HTTP协议为无链接的协议）；当使用 Keep-Alive 模式（又称持久链接、链接重用）时，Keep-Alive 功能使客户端到服务器端的链接持续有效，当出现对服务器的后继请求时，Keep-Alive 功能避免了创建或者从新创建链接。

在 HTTP 1.0 版本中，并无官方的标准来规定 Keep-Alive 如何工做，所以实际上它是被附加到 HTTP 1.0协议上，若是客户端浏览器支持 Keep-Alive ，那么就在HTTP请求头中添加一个字段 Connection: Keep-Alive，当服务器收到附带有 Connection: Keep-Alive 的请求时，它也会在响应头中添加一个一样的字段来使用 Keep-Alive 。这样一来，客户端和服务器之间的HTTP链接就会被保持，不会断开（超过 Keep-Alive 规定的时间，意外断电等状况除外），当客户端发送另一个请求时，就使用这条已经创建的链接。

在 HTTP 1.1 版本中，默认状况下全部链接都被保持，若是加入 "Connection: close" 才关闭。目前大部分浏览器都使用 HTTP 1.1 协议，也就是说默认都会发起 Keep-Alive 的链接请求了，因此是否能完成一个完整的 Keep-Alive 链接就看服务器设置状况。

因为 HTTP 1.0 没有官方的 Keep-Alive 规范，而且也已经基本被淘汰，如下讨论均是针对 HTTP 1.1 标准中的 Keep-Alive 展开的。

注意：

  • HTTP Keep-Alive 简单说就是保持当前的TCP链接，避免了从新创建链接。

  • HTTP 长链接不可能一直保持，例如 Keep-Alive: timeout=5, max=100，表示这个TCP通道能够保持5秒，max=100，表示这个长链接最多接收100次请求就断开。

  • HTTP是一个无状态协议，这意味着每一个请求都是独立的，Keep-Alive没能改变这个结果。另外，Keep-Alive也不能保证客户端和服务器之间的链接必定是活跃的，在HTTP1.1版本中也如此。惟一能保证的就是当链接被关闭时你能获得一个通知，因此不该该让程序依赖于Keep-Alive的保持链接特性，不然会有意想不到的后果。

  • 使用长链接以后，客户端、服务端怎么知道本次传输结束呢？两部分：1. 判断传输数据是否达到了Content-Length 指示的大小；2. 动态生成的文件没有 Content-Length ，它是分块传输（chunked），这时候就要根据 chunked 编码来判断，chunked 编码的数据在最后有一个空 chunked 块，代表本次传输数据结束，详见这里。什么是 chunked 分块传输呢？下面咱们就来介绍。

Transfer-Encoding

Transfer-Encoding 是一个用来标示 HTTP 报文传输格式的头部值。尽管这个取值理论上能够有不少，可是当前的 HTTP 规范里实际上之定义了一种传输取值——chunked。

若是一个HTTP消息（请求消息或应答消息）的Transfer-Encoding消息头的值为chunked，那么，消息体由数量未定的块组成，并以最后一个大小为0的块为结束。

每个非空的块都以该块包含数据的字节数（字节数以十六进制表示）开始，跟随一个CRLF （回车及换行），而后是数据自己，最后块CRLF结束。在一些实现中，块大小和CRLF之间填充有白空格（0x20）。

最后一块是单行，由块大小（0），一些可选的填充白空格，以及CRLF。最后一块再也不包含任何数据，可是能够发送可选的尾部，包括消息头字段。 消息最后以CRLF结尾。

注意： chunked 和 multipart 两个名词在乎义上有相似的地方，不过在 HTTP 协议当中这两个概念则不是一个类别的。multipart 是一种 Content-Type，标示 HTTP 报文内容的类型，而 chunked 是一种传输格式，标示报头将以何种方式进行传输。

HTTP Pipelining（HTTP 管线化）

默认状况下 HTTP 协议中每一个传输层链接只能承载一个 HTTP 请求和响应，浏览器会在收到上一个请求的响应以后，再发送下一个请求。在使用持久链接的状况下，某个链接上消息的传递相似于请求1 -> 响应1 -> 请求2 -> 响应2 -> 请求3 -> 响应3。

HTTP Pipelining（管线化）是将多个 HTTP 请求整批提交的技术，在传送过程当中不需等待服务端的回应。使用 HTTP Pipelining 技术以后，某个链接上的消息变成了相似这样请求1 -> 请求2 -> 请求3 -> 响应1 -> 响应2 -> 响应3。

注意下面几点：

  • 管线化机制经过持久链接（persistent connection）完成，仅 HTTP/1.1 支持此技术（HTTP/1.0不支持）

  • 只有 GET 和 HEAD 请求能够进行管线化，而 POST 则有所限制

  • 初次建立链接时不该启动管线机制，由于对方（服务器）不必定支持 HTTP/1.1 版本的协议

  • 管线化不会影响响应到来的顺序，如上面的例子所示，响应返回的顺序并未改变

  • HTTP /1.1 要求服务器端支持管线化，但并不要求服务器端也对响应进行管线化处理，只是要求对于管线化的请求不失败便可

  • 因为上面提到的服务器端问题，开启管线化极可能并不会带来大幅度的性能提高，并且不少服务器端和代理程序对管线化的支持并很差，所以现代浏览器如 Chrome 和 Firefox 默认并未开启管线化支持

更多关于 HTTP Pipelining 的知识能够参考这里。

HTTPS

HTTP协议是明文传输数据，在客户端和服务器之间截获通讯流量便可获取明文，好比代理服务器或者网关等；同时，对于服务器的真伪，客户端也没法鉴别。为了实现较安全的通讯，一般是用HTTPS来保证。

超文本传输安全协议（英语：Hypertext Transfer Protocol Secure，缩写：HTTPS，常称为HTTP over TLS，HTTP over SSL或HTTP Secure）是一种网络安全传输协议。在计算机网络上，HTTPS经由超文本传输协议进行通讯，但利用SSL/TLS来加密数据包。HTTPS开发的主要目的，是提供对网络服务器的身份认证，保护交换数据的隐私与完整性。

使用了HTTPS的网站，现代浏览器会在地址栏以绿色锁形标记进行提示。如：

更多关于 HTTPS 的知识参考维基百科-HTTPS

楚江数据是一家专业的互联网数据技术服务商，提供网站APP数据采集和爬虫软件定制开发服务，服务范围涵盖社交网络、电子商务、分类信息、学术研究等。
官方网站 http://www.chujiangdata.com。

整理自：

  1. https://hit-alibaba.github.io...

  2. http://www.ruanyifeng.com/blo...

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程