16-1-26---图解HTTP(01)

图解HTTP
1.4.2确保可靠性的HTTP协议
    按层次分,TCP位于传输层,提供可靠的字节流服务
    所谓字节流服务,指为了方便传输,将大块数据分割成以报文为单位的数据包进行管理,而可靠的传输服务是指,能够把数据准确可靠的传给对方。
    即TCP协议为了更加容易传送大数据才把数据分割,而且TCP协议能够确认数据最终是否送达到对方
    为了确认无误地将数据送达目标处,TCP协议采用三次握手策略。握手过程使用了TCP的标志位,SYN(synchronize)和ACK(acknowledgement)
    
    发送端首先发送一个带SYN标志的数据包给对方,接受端收到后,回传一个带有SYN/ACK标志的数据包以示传达确认信息。最后,发送端在回传一个带ACK标志的数据包,以代表“握手”结束。
    若握手过程中某个阶段莫名中断,TCP协议会再次以相同的顺序发送相同的数据包。
    
    三次握手
    标有syn的数据包发送给你了
                            明白,我收到你给我发送的数据包了(并发送标有syn/ack的数据包)
    明白,发送标有ack的数据包
    
    除了三次握手,TCP协议还有其他手段来保证通信的可靠性
    
1.5 负责域名解析的DNS服务
    DNS(Domain Name System) 服务是和HTTP协议一样位于应用层的协议,它提供域名到IP地址之间的解析服务。
    计算机既可以被赋予IP地址,也可以被赋予主机名和域名,比如: www.jrange.com
    
    DNS协议提供域名查找IP地址,或逆向从IP细致反查域名的服务
    我想访问www.jrange.com,把他的域名告诉我吧
                                        www.jrange.com对应的IP地址是20x.189.103.xxx
    向 20x.189.103.xxx 发送访问请求
    
1.6 各种协议与HTTP协议的关系
    这里需要补一张图, 《图解HTTP》P.31
1.7 URI & URL
    URI(Uniform-规定统一的格式方便处理多种不同类型的资源,而不用根据上下文环境来识别资源指定的访问方式,加入新增的协议方案也更加容易
             Resource-定义是“可以标识任何东西”,除了文档文件、图像或服务等能后区别于其他类型的,全部都可以作为资源。资源不仅可以是单一的,也可以是多数的集合体
             Identifier0表示可标识的对象,也称为标识符)统一资源标识符
             综上,URI就是由某个协议方案表示的资源的定位标识符
             协议方案是指访问资源所使用的协议类型名称
             采用HTTP协议时,协议方案就是http。除此之外,还有ftp,mailto,telnet,file等。
             URI用字符串标识某一互联网资源
    URL()统一资源定位符,表示资源的地点(互联网上所处的位置,)
    
    http://user:pass@www.example.jp:80/dir/index.htm?uid=1#ch1
    使用http: 或者 https: 等协议方案名获取访问资源时要指定协议类型。不区分大小写,最后附上一个冒号 (:)
    
    登录信息(认证)指定用户名和密码作为从服务器端获取访问资源时必要的登录信息(身份认证)
    服务器地址 使用绝对URI必须指定待访问的服务器地址。地址可以是类似 DNS可解析的名称, 或者是192.168.1.1这类IPv4地址名,也可以是[0:0:0:0:0:0:0:0:1]这样的IPv6地址名
    服务器端口号 指定服务器连接的网络端口号。用户省略则自动使用默认端口号
    带层次的文件路径 指定服务器上的文件路径来定位特指的资源。与unix系统的文件目录类似
    查询字符串 针对已经指定的文件路径内的资源,可以使用查询字符串传入任意参数
    片段标识 使用片段标识符通常可以标记出已获取资源中的子资源
    
注意并不是所有的应用程序都符合RFC
    一些用来制定HTTP协议技术标准的文档,他们被称为RFC Request for Comments 征求修正意见书
    
    
第二章 简单的HTTP协议

2.1 HTTP协议用于客户端和服务器端之间的通信
    HTTP协议和TCP/IP协议族内的其他众多的协议相同,用于客户端和服务器之间的通信
    请求访问文本或图像等资源的一端称为客户端,而提供资源响应的一端称为服务器端
    
    HTTP协议规定,请求从客户端发出,最后服务器端响应该请求并返回。肯定是先从客户端开始建立通信,服务器端在没有收到请求之前不会做出反应
    (1)发送请求
                GET / HTTP/1.1
                Host: jrange.com
                            (2)发送响应
                                    HTTP/1.1 200 OK
                                    Date: Tue, 10 Jul 2012 06:50:15 GMT
                                    Content-Length: 362
                                    Content-Type: text/html
                                    <html>
                                    。。。
    GET /index.htm HTTP/1.1
    Host: jrange.com
    
    起始行开头的GET表示请求访问服务器的类型,称为方法。随后的字符串/index.htm指明了请求访问的资源对象,也叫作请求URI(request-URI).
    这段请求内容的意思是:请求访问某台HTTP服务器上的/index.htm的页面资源
    请求报文是由请求方法、请求URI、协议版本、可选的请求首部字段和内容实体构成。
    
    POST /form/entry  HTTP/1.1
    方法  URI          协议版本
    
    Host:jrange.com
    Conntection: keep-alive
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 16
    请求首部字段
    
    name=ueno&age=37
    内容实体
    
    接收到请求的服务器会将请求内容的处理结果以响应的形式返回。
    HTTP/1.1 200     OK
    协议版本 状态码  状态码的原因短语
    
    Date: Tue, 10 Jul 2012 06:50:15 GMT
    Content-Length: 362
    Content-Type: text/html
    响应首部字段
    
    <html>
    ...
    主体
    
    在起始行开头的 HTTP/1.1表示服务器对应的HTTP版本。
    紧挨着的200 OK 表示请求的处理结果的状态码(status code)和原因短语(reason-phrase)下一行显示了创建响应的日期和时间,是首部字段内的一个属性。
    接着以一空行进行分割,之后的内容称为资源实体的主体(entity body)
    
    响应报文基本上由协议版本、状态码(表示请求成功或者失败的数字代码)、用以解释状态码的原因短语、可选的响应首部字段以及实体主体构成。
    
2.3 HTTP是不保存状态的协议
    HTTP是一种不保存状态,即无状态协议。HTTP协议自身不对请求和响应之间的通信状态进行保存。也就是说,在HTTP这个级别,协议对于发送过的请求或响应不做持久化处理
    使用HTTP协议,每当有新的请求发送时,就会有对应的新的响应产生,协议本身不对之前的一切请求或响应进行保存。
    这是为了更加快速的处理大量事务,确保协议的可伸缩性,特意把HTTP协议设计的如此简单。
    
    虽然HTTP/1.1 虽然是无状态协议,但是为了实现期望保持的状态功能,引入Cookie技术
2.4请求URI定位资源
    HTPP协议使用URI定位互联网上的资源。当客户端请求访问资源而发送请求时,URI需要将作为请求报文中的请求URI包含在内。
    完整的请求URI
        GET http://jrange.com/index.htm HTTP/1.1
        
        在首部字段host中写明网络域名或者IP域名
        GET /index.htm HTTP/1.1
        Host: jrange.com
        
        除此之外,如果不是访问特定资源而是对服务器本身发起请求,可以用一个 * 来代替请求URI。
        OPTIONS * HTTP/1.1
        
2.5 告知服务器意图的HTTP方法
GET 获取资源
    用来请求访问已被URI识别的资源,指定的资源经服务器端解析后返回响应的内容。也就是说,如果请求的资源是文本,就原样返回;如果是像是GCI (通用网关接口)那样的程序,则返回经过执行后的输出结果
POST 传输实体主体
    虽然用GET方法也可以传输实体,但是一般不用GET方法进行传输,而是用POST方法。虽说POST方法的功能和GET方法很相似,但是POST的方法主要目的并不是获取响应的主体实体。
PUT 传输文件
    就像FTP协议的文件上传一样,要求在请求报文的主题中包含文件内容,然后保存到请求URI指定的位置。
    但是鉴于PUT方法本事不带验证机制,任何人都可以上传文件,存在安全性问题,因此一般WEB网站不用该方法。若配合Web应用程序的验证机制,或架构设计采用REST标准的同类网站,就可能开放PUT的用法。
HEAD 获得报文首部
    HEAD方法和GET方法一样,只是不返回报文的主体部分。用于确认URI的有效性及资源更新的日期时间等。
    返回资源有关的响应首部    
DELETE 删除文件
    用来删除文件,与PUT相反的方法。同样是不带验证机制,所以一般也不开通。
OPTIONS 询问支持的方法
    用来查询针对请求URI指定的资源支持的方法(返回服务器支持的方法,如GET、POST、HEAD、OPTIONS)
TRACE 追踪路径
    让服务器端将之前的请求通信环回给客户端的方法
    发送请求时,在Max-Forwards首部字段中填入数值,每经过一个服务器该数字就减一,当数值刚好减到0时,就停止继续传输,最后接受到请求的服务器则返回状态码 200 OK 的响应。
    TRACE一般不常用,而且容易引发XST(跨站追踪)攻击,所以就更加不常用了 (!!从代理服务器路由中转时,原请求可能被篡改!!)
CONNECT 要求用隧道协议连接代理
    方法要求自代理服务器通信时建立隧道,实现用隧道协议进行TCP通信。主要用SSL(Secure Sockets Layer 安全套接层)和TLS(Transport Layer Security 传输层安全)协议把通信内容加密后经网络隧道传输。
    CONNECT 代理服务器名 : 端口号 HTTP版本
    例子:
    request
        CONNECT proxy.jrange.com HTTP/1.1
        Host: proxy.jrange.com
    response
        HTTP/1.1 200 OK(之后进入隧道)
2.6 使用方法下达命令
向请求URI指定的资源发送请求报文是,采用称为方法的命令。方法的作用在于,可以指定请求的资源按期望产生某种行为。
2.7持久连接节省通信流量
HTTP协议的初始版本中,每进行一次HTTP通信就要断开一次TCP连接。
    TCP建立连接
        SYN
                SYN/ACK
        ACK
        HTTP请求
                HTTP响应
                FIN
        ACK
        FIN
                ACK
                  断开TCP连接    
    2.7.1持久连接
        为了解决上述TCP连接的问题,HTTP/1.1 和一部分的 HTTP/1.0    想出了持久连接(HTTP Persistent Connections 也称为HTTP keep-alive 或者 HTTP connection reuse)
        持久的特点是,没有哪一端提出断开连接,则保持TCP连接状态。
        优点:减少了TCP连接的重复建立和断开造成的额外开销,减轻了服务器端的负载。另外,减少开销的那部分时间,是HTTP请求和响应能够更早地结束,这样WEB页面的显示速度也就相应提高
        毫无疑问,除了服务器端,客户端也需要支持持久化连接
    2.7.2 管线化
        持久连接使得多数请求以管线化方式发送成为可能。从前发送请求后,需要等待并接受到响应才能发送下一个请求,现在不用等待响应即发送请求
        这样就可以并行发送多个请求,不需要一个接一个地等待响应了。
2.8    使用Cookie的状态管理
    Cookie技术通过请求和响应报文中写入Cookie信息来控制客户端的状态。
    Cookie会根据服务器段发送的响应报文内的一个叫做Set-Cookie的首部字段信息,通知客户端保存Cookie。当下次客户端再往该服务器发送请求时,客户端会自动在请求报文中加入Cookie值后发送回去。
    服务器端发现客户端发送过来的Cookie后,回去检查究竟是从哪个客户端发送来的连接请求,然后对比服务器上的记录,最后得到之前的状态信息。

第三章 HTTP报文内的HTTP信息
3.1HTTP报文
    用于HTTP协议交互的信息被称为HTTP报文,请求端的HTTP报文叫做请求报文,响应端的报文叫做响应报文。
    HTTP报文是由多行(用CR+LF做换行符)数据构成的字符串文本
3.2请求报文及响应报文的结构
    请求行 包含请求的方法,请求URI和HTTP版本
    状态行 包含表明响应结果的状态码,原因短语和HTTP版本
    首部字段 包含请求和响应的各种条件和属性的各类首部   一般有4种首部字段,通信首部、请求首部、响应首部、实体首部
    其他。可能包含HTTP的RFC里未定义的首部 (Cookie等)
3.3编码提升传输速率
通过在传输时编码,能有效地处理大量的访问请求,但是,编码的操作需要计算机来完成,因此会消耗更多的CPU资源。
    3.3.1报文主体和实体主体的差异
    报文
        是HTTP通信中的基本单位,有8位字节流组成(octet sequence 其中octet为8个比特)组成,通过HTTP通信传输
    实体
        作为请求或者响应的有效载荷数据(补充项)被传输,其内容是有实体首部和实体主体构成。
    3.3.2 压缩传输的内容编码
        内容编码是指明应用在实体内容上的编码格式,并保持实体信息原样压缩。内容编码后的实体由客户端接收并负责解码。
        常用的内容编码有以下几种
            gzip GUN zip
            compress UNIX系统的标准编码
            deflate zlib
            identity 不进行编码
    3.3.3 分割发送的分块传输编码
        在HTTP通信中,请求的编码实体资源尚未全部传输完成之前,浏览器无法显示请求桌面。在传输大容量数据时,通过把数据分割成多块,能够让浏览器逐步显示页面
        这种把实体主体分块的功能称为分块传输编码(Chunked Transfer Coding)
        使用分块编码的实体主体会有接受客户端负责解码,恢复到编码前的实体主体
3.4 发送多种数据的多部分对象集合
        发送邮件时,我们可以在邮件里写入文字并添加多分附件。这是因为采用了MIME(Multipurpose Internet Mail Extensions 多用途因特网邮件扩展机制),它允许邮件处理文本、图片、视频等多个不同类型的数据。
        相应的,HTTP协议也采纳了多部分对象集合,发送一份报文主体可以包含多种类型实体,通常是在图片或文本文件等上传时使用。
        多部分对象集合包含的对象如下:
            multipart/form-data
                在web表单文件上传时使用
            multipart/byteranges
                状态码206(Partial Content, 部分内容)响应报文包含了读个范围的内容时使用。
            在HTTP报文中使用了多部分对象集合时,需要在首部字段里加上Content-type
            使用boundary字符串来划分多部分对象集合指明的各类实体。在boundary字符串指定的各个实体的起始行之前插入“--”标记,而在多部分对象集合对应的字符串的最后插入“--”标记作为结束。
3.5获取部分内容的范围请求
要实现该功能需要指定下载实体的范围。像这样指定范围发送的请求叫做范围请求Range Request
    GET /tip.jpg HTTP/1.1
    Host: www.jrange.com
    Range: bytes = 5001-10000
    
    Range: bytes = 5001-
    Range: bytes = -3000l, 5000-7000
    针对范围请求,响应会返回状态码为206 的响应报文。应为,对于多重范围的范围请求,响应会在首部字段Content-Type 表明multipart/byteranges后返回响应报文
    如果服务器端无法响应范围请求,则会在状态码200 OK 和完整的实体内容
3.6 内容协商返回最合适的内容
当浏览器的默认语言为英文时,访问相同的URI的WEB页面时,则会显示对应的英文版的WEB页面,这样的机制称为内容协商。
内容协商机制是指客户端和服务器端就响应的资源内容进行交涉,然后提供给客户端最为合适的资源。内容协商会以响应资源的语言,字符集、编码方式等作为判断标准。
    Accept
    Accept-Charset
    Accept-Encoding
    Accept-Language
    Content-Language
    服务器驱动协商(Server-driven Negotiation)
        由服务器端进行内容协商,以请求的首部字段为参考,在服务器端自动处理。
    客户端驱动协商(Agent-driven Negotiation)
        有客户端进行内容协商的方式,用户从浏览器显示的可选项列表中手动选择。还可以利用JavaScript脚本在Web页面上自动进行选择。
    透明协商(Transparent Negotiation)
        服务器端和客户端驱动结合体,是由服务器端和客户端各自进行内容协商的一种方法。

原文地址:https://www.cnblogs.com/ya-cpp/p/5164201.html