python爬虫基础01-HTTP协议

Posted 2021-12-24 winfun

深入浅出了解HTTP协议

 

HTTP（HyperText Transfer Protocol，超文本传输协议)是互联网上应用最为广泛的一种网络协议。目前使用最普遍的一个版本是HTTP 1.1。

HTTP协议是用于从WWW服务器传输超文本到本地浏览器的传送协议。它可以使浏览器更加高效，使网络传输减少。它不仅保证计算机正确快速地传输超文本文档，还确定传输文档中的哪一部分，以及哪部分内容首先显示(如文本先于图形)等。

 

HTTP协议简介

HTTP是一个应用层协议，由请求和响应构成，是一个标准的客户端-服务端结构。

一次HTTP请求的基本流程一般是，在建立TCP连接后，由客户端向服务端发起一次请求（request），而服务器在接收到以后返回给客户端一个响应（response）。

所以我们看到的HTTP请求内容一般就分为请求和响应两部分。

HTTP协议通常承载于TCP协议之上，有时也承载于TLS或SSL协议层之上，这个时候，就成了我们常说的HTTPS。

默认HTTP的端口号为80。

 

HTTP协议特点

• 灵活

  HTTP允许传输任意数据的数据对象，传输的类型由Content-Type标记

• 无连接

  每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。

• 无状态

  也就是说每一次HTTP请求之间都是相互独立的，没有联系的，服务端不知道客户端具体的状态。

  比如客户端访问一次网页之后关闭浏览器，然后再一次启动浏览器，再访问该网站，服务器是不知道客户关闭了一次浏览器的。

  这样设计的原因是因为Web服务器一般需要面对很多浏览器的并发访问，为了提高Web服务器对并发访问的处理能力，在设计HTTP协议时规定Web服务器发送HTTP应答报文和文档时，不保存发出请求的Web浏览器进程的任何状态信息。

 

URL

URL（Uniform Resource Locator），中文叫统一资源定位符。是用来标识某一处资源的地址。以下面这个URL为例，介绍下普通URL的各部分组成：

1. 协议部分：该URL的协议部分为“http：”，这代表网页使用的是HTTP协议。在"HTTP"后面的“//”为分隔符。

2. 域名部分：该URL的域名部分为“www.aspxfans.com”。一个URL中，也可以使用IP地址作为域名使用。

3. 端口部分：跟在域名后面的是端口，域名和端口之间使用“:”作为分隔符。端口不是一个URL必须的部分，如果省略端口部分，将采用默认端口。

4. 路径部分：从域名后的第一个“/”开始到最后一个“？”为止，是路径部分，如果没有“?”,则是从域名后的最后一个“/”开始到“#”为止，是路径部分，如果没有“？”和“#”，那么从域名后的最后一个“/”开始到结束，都是路径部分。

   本例中的文件名是“index.asp”。文件名部分也不是一个URL必须的部分，如果省略该部分，则使用默认的文件名。

5. 参数部分：从“？”开始到“#”为止之间的部分为参数部分。本例中的参数部分为“boardID=5&ID=24618&page=

6. 1”。参数可以允许有多个参数，参数与参数之间用“&”作为分隔符。

7. 锚部分：从“#”开始到最后，都是锚部分。本例中的锚部分是“name”。锚部分也不是一个URL必须的部分。

   锚部分是用来定位到页面中某个元素的。

 

 

HTTP请求

每一个HTTP请求都由三部分组成，分别是：请求行、请求报头、请求正文。

请求行

请求行一般由请求方法、url路径、协议版本组成，以空格分开，如下所示：

请求报头

请求行下方的是则是请求报头，HTTP消息报头包括普通报头、请求报头、响应报头、实体报头。每个报头的形式如下：

名字 + : + 空格 + 值

• Host

  指定的请求资源的域名（主机和端口号）。HTTP请求必须包含HOST，否则系统会以400状态码返回。

• User-Agant

  简称UA，内容包含发出请求的用户信息，通常UA包含浏览者的信息，主要是浏览器的名称版本和所用的操作系统。这个UA头不仅仅是使用浏览器才存在，只要使用了基于HTTP协议的客户端软件都会发送，无论是手机端还是PDA等，这个UA头是辨别客户端所用设备的重要依据。

• Accept

  告诉服务器客户端可以接受那些类型的信息。

• Cookie

  Cookie信息。

• Cache-Control

  指定请求和响应遵循的缓存机制。在请求消息或响应消息中设置Cache-Control并不会修改另一个消息消息处理过程中的缓存处理过程。请求时的缓存指令包括no-cache、no-store、man-age、max-stake、min-fresh、only-if-cached；响应消息中的指令包括 public、privete、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age。

• Referer

  页面跳转处，表明产生请求的网页来自于哪个URL，用户是从该 Referer页面访问到当前请求的页面。这个属性可以用来跟踪Web请求来自哪个页面，是从什么网站来的。

• Content-Type

  来表示具体请求中的媒体类型信息,例如 text/html 代表 HTML 格式，image/gif 代表 GIF 图片，application/json 代表 Json 类型

• Content-Length

  内容长度。

• Content-Range

  响应的资源范围。可以在每次请求中标记请求的资源范围，在连接断开重连时，客户端只请求该资源未下载的部分，而不是重新请求整个资源，实现断点续传。迅雷就是基于这个原，使用多线程分段读取网络上的资源，最后再合并。

• Accept-Encoding

  指定所能接收的编码方式，通常服务器会对页面进行GZIP压缩后再输出以减少流量，一般浏览器均支持对这种压缩后的数据进行处理，但对于我们来说，如果不想接收到这些看似乱码的数据，可以指定不接收任何服务器端压缩处理，要求其原样返回。

• Accept-Language

  指浏览器可以接受的语言种类 en、en-us指英语 zh、zh-cn指中文。

• Connection

  客户端与服务器链接类型，keep-alive:保持链接，close:关闭链接。

请求正文

请求正文通常是使用POST方法进行发送的数据，GET方法是没有请求正文的。

请求正文跟上面的消息报头一般由一个空行隔开。

 

HTTP响应

HTTP响应同样也是由状态行、响应报头、报文主体三部分组成。

状态行

状态行由HTTP协议版本号， 状态码， 状态消息三部分组成。如下所示：

响应报头

• Allow

  服务器支持哪些请求方法（如GET、POST等）。

• Date

  表示消息发送的时间，时间的描述格式由rfc822定义。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的时间表示世界标准时，换算成本地时间，需要知道用户所在的时区。

• Set-Cookie

  非常重要的header, 用于把cookie发送到客户端浏览器，每一个写入cookie都会生成一个Set-Cookie。

• Expires

  指定 Response 的过期时间 ，从而不再缓存它，重新从服务器获取，会更新缓存。过期之前使用本地缓存。降低服务器负载，缩短加载时间。

• Content-Type

  WEB服务器告诉客户端自己响应的对象的类型和字符集。

• Content-Encoding

  文档的编码（Encode）方法。只有在解码之后才可以得到Content-Type头指定的内容类型。利用gzip压缩文档能够显著地减少HTML文档的下载时间。

• Content-Length

  指明实体正文的长度，以字节方式存储的十进制数字来表示。

• Location

  用于重定向一个新的位置，包含新的URL地址。表示客户应当到哪里去提取文档。

• Refresh

  表示浏览器应该在多少时间之后刷新文档，以秒计。

响应正文

服务器返回的数据。

 

HTTP请求方法

HTTP协议中定义的请求方法有以下几种：

序号	方法	描述
1	GET	请求指定的页面信息，并返回实体主体。
2	HEAD	类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头
3	POST	向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
4	PUT	从客户端向服务器传送的数据取代指定的文档的内容。
5	DELETE	请求服务器删除指定的页面。
6	CONNECT	HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
7	OPTIONS	允许客户端查看服务器的性能。
8	TRACE	回显服务器收到的请求，主要用于测试或诊断。

虽然HTTP请求中定义的方法有这么多种，但是我们平常使用的基本只有GET和POST两种方法，而且大部分网站都是禁用掉了除GET和POST外其他的方法。

因为其他几种方法通过GET或者POST都能实现，而且对于网站来说更加的安全和可控。

• GET

  其实简单来说，GET方法一般用来负责获取数据，或者将一些简短的数据放到URL参数中传递到服务器。比POST更加高效和方便。

• POST

  由于GET方法最多在url中携带1024字节数据，且将数据放到URL中传递太不安全，数据量大时URL也会变得冗长。所以传递数据量大或者安全性要求高的数据的时候，最好使用POST方法来传递数据。

 

状态码（status code）

当客户端向服务端发起一次请求后，服务端在返回的响应头中会包含一个HTTP状态码。

HTTP的状态码是由三位数字来表示的，由第一位数字来表示状态码的类型，一般来说有五种类型：

分类	分类描述
1**	信息，服务器收到请求，需要请求者继续执行操作
2**	成功，操作被成功接收并处理
3**	重定向，需要进一步的操作以完成请求
4**	客户端错误，请求包含语法错误或无法完成请求
5**	服务器错误，服务器在处理请求的过程中发生了错误

以下是详细的状态码列表：

状态码	状态码英文名称	中文描述
100	Continue	继续。客户端应继续其请求
101	Switching Protocols	切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议
200	OK	请求成功。一般用于GET与POST请求
201	Created	已创建。成功请求并创建了新的资源
202	Accepted	已接受。已经接受请求，但未处理完成
203	Non-Authoritative Information	非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本
204	No Content	无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档
205	Reset Content	重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域
206	Partial Content	部分内容。服务器成功处理了部分GET请求
300	Multiple Choices	多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择
301	Moved Permanently	永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替
302	Found	临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI
303	See Other	查看其它地址。与301类似。使用GET和POST请求查看
304	Not Modified	未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源
305	Use Proxy	使用代理。所请求的资源必须通过代理访问
306	Unused	已经被废弃的HTTP状态码
307	Temporary Redirect	临时重定向。与302类似。使用GET请求重定向
400	Bad Request	客户端请求的语法错误，服务器无法理解
401	Unauthorized	请求要求用户的身份认证
402	Payment Required	保留，将来使用
403	Forbidden	服务器理解请求客户端的请求，但是拒绝执行此请求
404	Not Found	服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面
405	Method Not Allowed	客户端请求中的方法被禁止
406	Not Acceptable	服务器无法根据客户端请求的内容特性完成请求
407	Proxy Authentication Required	请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权
408	Request Time-out	服务器等待客户端发送的请求时间过长，超时
409	Conflict	服务器完成客户端的PUT请求是可能返回此代码，服务器处理请求时发生了冲突
410	Gone	客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置
411	Length Required	服务器无法处理客户端发送的不带Content-Length的请求信息
412	Precondition Failed	客户端请求信息的先决条件错误
413	Request Entity Too Large	由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息
414	Request-URI Too Large	请求的URI过长（URI通常为网址），服务器无法处理
415	Unsupported Media Type	服务器无法处理请求附带的媒体格式
416	Requested range not satisfiable	客户端请求的范围无效
417	Expectation Failed	服务器无法满足Expect的请求头信息
500	Internal Server Error	服务器内部错误，无法完成请求
501	Not Implemented	服务器不支持请求的功能，无法完成请求
502	Bad Gateway	充当网关或代理的服务器，从远端服务器接收到了一个无效的请求
503	Service Unavailable	由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中
504	Gateway Time-out	充当网关或代理的服务器，未及时从远端服务器获取请求
505	HTTP Version not supported	服务器不支持请求的HTTP协议的版本，无法完成处理

 

 

Cookie

Cookie有时也用其复数形式 Cookies，英文是饼干的意思。指某些网站为了辨别用户身份、进行 session 跟踪而储存在用户本地终端上的数据（通常经过加密）。最新的规范是 RFC6265  。

Cookie其实就是由服务器发给客户端的特殊信息，而这些信息以文本文件的方式存放在客户端，然后客户端每次向服务器发送请求的时候都会带上这些特殊的信息。 服务器在接收到Cookie以后，会验证Cookie的信息，以此来辨别用户的身份。

Cookie可以理解为一个临时通行证。

作用

Cookie其实是HTTP请求头的扩展部分，由于HTTP协议是无状态的协议，所以为了在网页上实现登陆之类的需求，所以扩展了Cookie这样的功能。

每一次HTTP请求在数据交换完毕之后就会关闭连接，所以下一次HTTP请求就无法让服务端得知你和上一次请求的关系。而使用了Cookie之后，你在第一次登陆之类的请求成功之后，服务器会在Response的头信息中给你返回Cookie信息，你下一次访问的时候带上这个Cookie信息，则服务器就能识别你为上一次成功登陆的用户。

内容

Cookie一般保存的格式为json格式，由一些属性组成。

• name：Cookie的名称

• value：Cookie的值

• domain：可以使用此Cookie的域名

• path：可以使用此Cookie的页面路径

• expires/Max-Age：此Cookie的超时时间

• secure：设置是否只能通过https来传递此条Cookie

domain属性

域名一般来说分为顶级域名，二级域名，三级域名等等。

例如baidu.com是一个顶级域名，而www.baidu.com和map.baidu.com就是二级域名，依次类推。

而在我们的Cookie来说，都有一个domain属性，这个属性限制了访问哪些域名时可以使用这一条Cookie。因为每个网站基本上都会分发Cookie，所以domain属性就可以让我们在访问新浪时不会带上百度分发给我们的Cookie。

而在同一系的域名中，顶级域名是无法使用其二级域名的Cookie的，也就是说访问baidu.com的时候是不会带上map.baidu.com分发的Cookie的，二级域名之间的Cookie也不可以共享。但访问二级域名时是可以使用顶级域名的Cookie的。

path属性

path属性为可以访问此cookie的页面路径。 比如domain是abc.com，path是/test，那么只有/test路径下的页面可以读取此cookie。

expires/Max-Age属性

字段为此cookie超时时间。若设置其值为一个时间，那么当到达此时间后，此cookie失效。不设置的话默认值是Session，意思是cookie会和session一起失效。当浏览器关闭(不是浏览器标签页，而是整个浏览器) 后，此cookie失效。

 

Session

Session，中文经常翻译为会话，其本来的含义是指有始有终的一系列动作/消息，比如打电话时从拿起电话拨号到挂断电话这中间的一系列过程可以称之为一个session。这个词在各个领域都有在使用。

而我们web领域，一般使用的是其本义，一个浏览器窗口从打开到关闭这个期间。

Session的目的则是，在一个客户从打开浏览器到关闭浏览器这个期间内，发起的所有请求都可以被识别为同一个用户。而实现的方式则是，在一个客户打开浏览器开始访问网站的时候，会生成一个SessionID，这个ID每次的访问都会带上，而服务器会识别这个SessionID并且将与这个SessionID有关的数据保存在服务器上。由此来实现客户端的状态识别。

Session与Cookie相反，Session是存储在服务器上的数据，只由客户端传上来的SessionId来进行判定，所以相对于Cookie，Session的安全性更高。

一般SessionID会在浏览器被关闭时丢弃，或者服务器会验证Session的活跃程度，例如30分钟某一个SessionID都没有活跃，那么也会被识别为失效。