16-1-26---图解HTTP（01）

时间 2019-11-12

标签图解 http 栏目 HTTP/TCP 繁體版

原文原文链接

图解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）
       服务器端和客户端驱动结合体，是由服务器端和客户端各自进行内容协商的一种方法。html