http协议基础

本文主要介绍http的协议基础:主要包括报文的结构、请求的方法、url、状态码、header,以及http的连接

报文协议

组成部分

  • 起始行

    Http报文
    如图:
    请求报文起始行:方法 url 协议类型
    响应报文起始行:协议类型 响应码 响应码的说明

  • 首部

    部首就是一系列键值对组合,用来说明连接及主体的数据的意义。下边会着重介绍请求与响应报文的相应首部。

  • 主体

    由任意数据组成的数据块。如上可以直接是字符串,上传的文件,表单等数据。

方法

方法描述是否包含主体
GET从服务器获取资源N
HEAD只获取资源的首部N
POST发送需要处理的数据Y
PUT将主体部分存储在服务器上Y
PATCH也是一种更新数据Y
TRACE追踪报文路径N
OPTIONS在服务器上可以执行哪些方法N
DELETE从服务器上删除文件.与put相对N
  • HEAD
    与GET行为类似,但服务器只返回首部。一般用于:

    • 通过状态码,查看资源是否存在
    • 在不获取资源情况下了解资源的类型
    • 通过首部,测试资源是否被修改?【这个还不明白,难道是对比资源的长度】
  • PUT、POST、PATCH
    put方法与post方法都是往服务器上传数据。put语义是让服务器用请求主体数据来创建一个由所请求url命名的新文档。如果已经存在,则替换它。
    post将表单数据发送的服务器。
    现在这里文件上传时,一般也是用post表单的方式上传。
    put区分?

  • TRACE
    TRACE方法
    如上图所示,主要用于验证请求穿过的代理

  • OPTIONS
    用于请求服务器告知其支持的各种方法.

URL

  • 组成部分
    http://www.joes-hardware.com/seasonal/index-fall.html
    由3部分组成:

    • 协议类型(scheme),https/http/ftp等等
    • 服务器位置,域名
    • 资源路径
  • 格式
    <scheme>://<user>:<password>@<host>:<port>/<path>?<param>?<query>#<frag>

状态码

  • 分类:

    整体范围已定义范围分类
    100-199100-101信息提示
    200-299200-206成功
    300-399300-305重定向
    400-499400-415客户端错误
    500-599500-505服务器错误
  • 常见:

    状态码原因说明
    200OK
    201Created创建成功
    202Accepted请求被接受
    300Multiple Choicesurl指向多个资源,Location
    301Moved PermanentlyURL被移到Location
    302FoundURL临时定位资源到Location
    400Bad Requese错误请求
    401Unauthorized未授权,未登录
    403Forbidden禁止访问
    404Not Found没有url对应资源
    405Method Not Allowed
    406Not Acception客户端指令资源类型,服务器没有
    500InternelServerErro服务器内部错误
    502Bad Gateway代理无法连接到父网关
    503Service Unavailabe服务器无法提供服务
  • 通用首部
    客户端与服务端通用的首部,常见如下

    首部描述
    Connection指定请求/响应连接有关选项
    Date报文创建时间
    Transfer-Encoding报文编码的方式
    Trailer报文采用分块传输编码时,列出报trailer信息
    viatrace方法时,经过的中间节点
    Cache-Control随报文传送缓存指示
  • 请求首部
    客户端特有首部,为服务器提供一些额外的(客户端)信息。

    首部描述
    Client-IP客户端ip
    From客户端email
    Host请求服务器的ip与端口(一般是url)
    Referer浏览器发送请求的时候一般会带上Referer,告诉服务器该网页是从哪个页面链接过来的
    User-Agent浏览器名
    Accept告知服务器应该发送那些类型
    Accept-Charset告知服务器字符集
    Accept-Encoding告知服务器编码方式
    If-Match条件请求:标记匹配,则请求
    Authorization安全请求:认证数据
    Cookie安全请求:cookie
  • 响应首部
    服务器特有首部,为客户的提供信息

    首部描述
    Age响应持续时间
    Public服务器为其资源提供的请求方法列表
    Proxy-Authenticate安全响应:代理对客户端的质询列表
    Set-Cookie安全响应:设置cookie
    WWW-Authenticate安全响应:服务器对客户端的质询列表
  • 实体首部
    用于对应主体部分的首部

    首部描述
    Content-Type主体类型
    Content-Length主体长度或尺寸
    Content-Location资源实际所处位置
    Content-Encoding主体编码方式
    Content-MD5主体MD5校验和
    Content-Base相对URL的基URL
    Last-Modified实体最后一次被修改的时间
    Expires实体过期,要从源端再次获取时间与日期

连接

Connection首部

浏览器与服务器之间,可以经过很多层代理,整个连接被分成了好多块小的连接。Connection首部由一个逗号分隔的标签列表,这些标签指定了在小连接之间的选项,不会传播到其它小连接上去。
接收端接收到Connection首部时,首先会解析这些选线,并将其应用。然后在此报文转发给下一跳之前,删除Connection首部及列表中的所有首部。

http首部字段名标签包括:
Http首部字段名,列出只与此连接相关的首部
任意标签值,用于描述此连接的非标准选项
close,说明操作完成之后需关这条连接。

串行加载

串行连接
如上图,一个网页有3个图片,串行加载需要4个http事物来显示页面,每个事物都需要建立一个新的连接,这样整个网页加载的速度就会累加起来。

并行连接

并行连接
如图,并行连接就是并发4个连接去请求资源,这样加载速度就会提升。
并行连接受到带宽、内存的影响,会引起很多问题。
一般浏览器确实使用并行连接,但连接数会很小(通常4个)。

持久连接

持久连接
如图,持久连接就是4个资源在一个连接中去请求,这样就避免了重新建立连接带来的延时。

  • Keep-Alive操作
    客户端通过Connection:Keep-Alive首部请求持久连接
    服务器如果愿意建立持久连接,就在相应首部中返回Connection:Keep-Alive,反之没有
    客户端若接收到Keep-Alive,则建立持久连接,反之就会关闭连接。

  • 哑代理
    哑代理就是一些老代理,他们不支持持久连接,而且会转发所有的首部,包括Connection:Keep-Alive。这样就造成浏览器与服务器都认为可以建立持久连接,而哑代理却忽略与客户端连接上的再次请求(半关闭),造成持久连接失败。

    一种解决方案:Proxy-Connection。这里就不展开了,这种方案也存在问题,仅当服务器与浏览器之间存在一个代理时可用。反之不可。

  • http/1.1持久连接
    http/1.1用Persistent Connection来代替Keep-Alive.Http/1.1持久连接在默认情况下是激活的,需要关闭时显示添加Connection:close首部来关闭。

管道化连接

管道化持久连接
HTTP/1.1允许在建立可选的请求管道。在相应到达之前,经多条请求放入发送队列。

  • 连接关闭
    任何一种技术都会有其要解决的问题,也有其带来的问题,如管道连接。管道连接带来的问题是由于服务器可以随意关闭连接,客户端发送出的连接还未到达,连接就关闭了,这样就造成了客户端并不知道发送的数据到了没有。另外服务器永远无法确定在关闭“空闲”连接那一刻,在线路另一端有没有数据要发送。
    这个挺费解的,tcp关闭是4次握手,一端关闭会发送关闭,等待ack后才进入半关闭状态?

    每条HTTP响应都应有精确的Content-Length首部。这样接收端可以根据若实体长度与Content-Length匹配来确定连接是否完成。

网络结构

web服务器

  • 概述:

    Web服务器逻辑实现了HTTP协议,管理着Web资源,并负责提供Web服务器的管理功能。

  • 小实现:跟tcp服务端编写一样

    Web服务器

    • 建立连接:接受一个客户端连接
    • 接收请求:从网络中读取一条HTTP请求报文
    • 处理请求:对请求报文进行解释,并采取行动
    • 访问资源:访问报文中指定的资源
    • 构建响应:构建带有正确首部的HTTP响应报文
    • 发送响应:将相应报文发送给的客户端
    • 记录事务处理过程:将事务有关的内容记录在日志文件中

中间商

代理

代理位于客户端与服务器之间,于是它既是服务器也是客户端。Http客户端会向代理发生报文,代理必须像Web服务器一样,正确地处理请求和连接,然后返回响应。同时,代理自身要向服务器发送请求。
攻守兼备_

代理vs网关
严格说,代理连接的是2个使用相同协议的应用程序,而网关是不同协议,但其实人为设定,它们从设计模式上看,都是代理。

类型

  • 出口代理
    本地网络的出口,便于控制本地网络与外部网络之间的流量。小学使用出口代理防止早熟的少年浏览不该浏览的内容。

  • 反向代理
    部署在Web服务器前,处理所有传送给Web服务器的求,并只在必要时间向Web服务器请求资源。如:Nginx。感觉这才是入口代理。

  • 网络交换代理(中间代理)
    可以将具有足够能力的代理放在网络之间的对等交换点上,通过缓存在减轻因特网节点的拥堵,并对流量进行监视。
    PS:这一块书上表述不清,它的入口代理感觉就是缓存,也就是这里的交换代理,故删掉。

代理获取流量的方式

  • 修改客户端
    手动修改浏览器的代理配置

  • 修改网络【拦截】
    通过网络基础设施(交换机、路由器),通过技术手段在没有客户端参与情况下,拦截网络流量并将其导入代理。

  • 修改DNS的命名空间【反向代理】
    反向代理会直接加班Web服务器的名字和IP。可以手动编辑DNS名称列表,或者用特殊的动态DNS服务器根据需要来确定适当的代理或者服务器。

  • 修改Web服务器
    重定向命令到代理上

与代理相关问题

  • 代理请求URI与服务器uri差异
    客户端向web服务器发送请求,请求行只包括部分URI;而向代理发送,会包含全部

    GET /index.html HTTP/1.0
    User-Agent: SuperBrowser v1.3
    
    GET http://www.marys-antiques.com/index.html HTTP/1.0
    User-Agent: SuperBrowser v1.3
    
  • 拦截和反向代理对主机信息的隐藏

Trace

  • TRACE方法
  • Via首部

Options

由于客户端、服务器、代理实现不同版本HTTP规范,以及对特性支持各不相同,可能会存在一些棘手问题。
可以通过OPTIONS方法,客户端(代理)可以发现Web服务器或者某个特定资源所支持的功能(所支持的方法)。这样在正式交互之前,确定服务器的能力。

缓存

  • 代理解决的问题:慢

    • 冗余数据传输
    • 带宽瓶颈
    • 瞬时拥塞
    • 距离延时
  • 处理问题所用的方法

    缓存命中
    如图即可,采用的方法与电脑的缓存相同。

  • 代理的处理步骤:对比服务器7步骤

    缓存步骤

    • 接收:缓存请求报文
    • 解析:解析报文,提出URL与首部
    • 查询:查询是否有本地副本可用,没有就获取一份,并存在本地
    • 新鲜度检测:就是确定数据一致性
    • 创建响应
    • 发送响应
    • 日志

    则合理用过If-Modified-Since/If-None-Match等首部

  • 其他

    • 为了保证新鲜度(数据一致性)采用了很多的算法,这里不在叙述了
    • 缓存和广告:这个挺有意思
      ISP的很多收益通过广告来实现,每次点击广告就收取一定的收益。而代理会隐藏实际的次数,这样就使服务器收益降低。_

网关

  • 网关要解决的问题

    网络上的资源太多了,这些资源的获取使用不同的协议来访问,于是通过http就不能实现对资源的访问。从一个角度上看,网关就是协议的转换,将http转换成其他协议来实现资源的访问,从另一个角度看,网关就是把其他协议访问资源做http代理,使其能被共有的http协议访问。

  • 几种网关

    • 协议网关:HTTP/FTP服务器端FTP网关
      HTTP_FTP网关
      网关接收到请求后,会打开一条与FTP服务器端口(21)的FTP连接,通过FTP协议获取对象。

    • 协议网关:HTTPS/HTTP客户端安全网关
      http_https网关
      对http进行加密,对https进行解密完成协议转换。

    • 资源网关:HTTP/CGI服务器端应用程序网关
      资源网关其实就是服务器,这时候它不是返回文件,而是调用应用程序。
      CGI(Common Gateway Interface):其实就是Web服务器调用应用程序的接口,Web服务用它来装载程序以响应URL的请求,并收集程序的输出数据,将其在http响应中回送。

隧道

  • 概述
    web隧道允许用户通过HTTP连接发送非HTTP流量,这样可以在http上稍带其他协议数据。使用web隧道最常见的原因是在http连接中嵌入非http流量,这样,这些流量就可以穿过只允许web流量穿过的防火墙。
    隧道
    隧道就是用http报文发送ssl协议报文,来穿过防火墙。

  • SSL与http/https网关对比
    网关需要完整的ssl实现,来完成http/https的转换
    隧道连接本质是ssl,只是中间一段用http报文来传输。

Web客户端:爬虫

爬虫

  • 爬虫是一种机器人,它们会递归的对各种web站点进行遍历,获取第一个web页面,然后从那个页面中解析指向的其他页面,接着爬取那些页面,依次类推的爬取。

  • 根集选择
    在Web结构中,有些页面是独立的,没有任何连接指向它们。

爬虫面对的问题

  • 机器人爬行时,要避免环路。环路就是几个页面相互引用成环,使爬虫一直在这些页面中重复爬行。

  • 文件系统连接环路
    指的通过符号链接,在子文件中指向父文件而造成的环路。

  • 动态虚拟web空间
    有的应用程序可以在传输中构造出包含同一服务器上虚拟URL连接的HTML。 当爬虫去请求时,这个“邪恶”的服务器会捏造出带有新的URL的新HTML来。

爬虫HTTP

鼓励爬虫加入一些识别首部,这样在追踪错误爬虫时,或者向服务器提供爬虫所能处理内容类型时,是有用的。

  • User-Agent
    将爬虫的名字告知服务器

  • From
    提供机器人管理者的email

  • accept
    告知服务器可以发送哪些类型(文本、图片等)

  • referer
    有些站点管理者尝试记录机器人是如何找到其站点的

  • host
    一个主机有多个域名,若不指明host,可能获取错内容。

爬虫要遵守的规范:robots.txt

  • web服务器可以在服务器文档根目录提供一个可选的、名为robots.txt的文件。这个文件说明机器人可以访问服务的哪些部分。

  • 爬虫在请求页面时,要先去查看robots.txt文件,看它是否有访问的权限。

  • robots.txt文件的格式
    User-Agent:slurp
    User-Agent: webcrawler
    Disallow:/private

    User-Agent:*
    Disallow

    以一个或者多个User-Agent开始,说明哪些机器人会受此记录影响,然后跟着Disallow和Allow,说明这些机器人可以访问哪些URL

爬虫的应用:搜索引擎

搜索引擎爬虫搜索web页面,然后将内容添加全文索引数据库中。用户引擎文章对全文索引进行查询。

客户端识别

概述

  • 无状态
    HTTP最初是一个匿名、无状态的请求/响应协议。服务器处理来自客户的请求,然后向客户回送一条响应。web服务器几乎没有什么信息可以判断是哪个用户发送的请求,也无法记录访问用户的请求序列。
  • 有状态
    现在,他们需要对客户端有更多的了解,并在用户浏览页面时,对其进行跟踪。
    如今一般在用的技术有:用户登录、胖url、cookie(ip技术已经基本淘汰)

ip

早期开发者曾尝试将客户端的ip地址作为一种标识形式使用。web服务器可以找到http对应的tcp连接,调用类似与getpeername(tcp_socket,...)函数来获取ip

  • 存在问题:
    1.ip记录的是机器,而不是用户,在多人共享一台机器时就无法区分。
    2.动态分配ip
    1. NAT防火墙会隐藏后边那些实际客户端的ip
    2. 代理的存在,web服务看到的是代理的ip

用户登录:Authorization首部,即认证

  • 用户访问服务器
  • 服务器返回401
  • 浏览器显示登录框
  • 在请求时用Authorization首部在下一条对服务器请求提供这些信息
    这个部分就是基本认证部分:
    基本认证

胖url

  • web服务器为每个用户生成特定版本的URL来追踪用户的身份。通常会对真正的URL进行扩展,在URL路径结束的地方添加一些状态信息。用户浏览网页时,web服务器动态生成一些超连接,继续维护URL中的状态信息。

  • 存在问题:
    丑陋的url
    无法共享URL,共享时可能泄密
    破坏缓存,不再有可供公共访问的url需要缓存
    额外的服务器负荷

  • cookie如何工作
    cookie
    首次访问时,web服务器给用户“拍上”一个独有的cookie,浏览器记住服务器返回Set-Cookie首部中cookie内容,并将cookie存储在浏览器的cookie数据库中。将来用户访问同一站点时,浏览器会挑中那个服务器用户上的cooike,将其传送回去。

  • cookie组成
    网景的cookie会将cookie存在一个cookies.txt文本文件中如:

名称说明
domainwww.fedex.com
allhFALSE是域中所有的主机都获取cookie?
path/域中与cookie相关的路径前缀
secureFALSE是否只有SSL才发送这个cookie
expiration1136109676过期时间间隔
namecccookie变量的名字
value/us/cookie变量的值

domain:
告诉浏览器,只有往这个域访问时才使用此cookie
set-cookie: user="mary17"; domain="airtravelbargains.com"

path:
告诉浏览器,只有往域的这个路径访问时,才是有此cookie
set-cookie: user="mary17"; domain="airtravelbargains.com"; path=/autos/

评论

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×