HTTP协议1

001.HTTP协议 Hypertext Transfer Protocal 超文本传输协议（超文本的意思就是不仅仅是文本，还有图片、视频、音频等）
    一种无状态的、应用层的、基于连接的以请求/应答方式运作的协议，它使用可扩展的语义和自描述消息格式，与基于网络的超文本信息系统灵活的交互
002.HTTP协议要解决什么问题
    问题的大前提是为了让人和计算机能够交互，即要使得人能够理解计算机上展现出来的数据，这就需要浏览器能够展示人类能够看懂的信息，想象一下解决整个人类（跨国家，跨地区，跨语言，跨种族的）
    那么就要求在浏览器端进行数据处理的组件要具备以下特性
    低门槛  即使用起开相对简单，开发成本地（比如早期的Java Alpanet和现在的JavaScript）
    可扩展性：巨大的用户群体，超长的寿命
    Internet规模
      .无法控制的Scalability
      .独立的组件部署，新老组件并存
      .向前兼容
    
003.使用ABNF（扩充巴科斯-瑙尔范式操作符，它是一种定义语法的元语言）语言来描述HTTP协议，RFC文档，它是对协议最权威的定义。
004.一个标准的http请求是
    GET / HTTP/1.1
    Host:www.baidu.com
    一个标准的应答体形如
    HTTP/1.1 200 OK
    Date: Tue, 26 Mar 2019 02:39:11 GMT
    Content-Type: application/octet-stream
    Transfer-Encoding: chunked
    Connection: keep-alive
005.使用ABNF来表示一个http请求
    HTTP-message = start-line *(header-field CRLF) CRLF [ message-body ]
    .start-line = request-line / status-line
      .request-line = method SP request-target sp HTTP-version CRLF
      .status-line = HTTP-version SP status-code SP reason-phrase CRLF
    .header-field = field-name":"OWS field-value OWS
     .OWS = *(SP/HTAB)
     .field-name = token
     .file-value = *(field-content / obs-fold)
    .message-body = *OCTET
006.在XSHELL下新建连接选择TELNET 主机loclhost
    进入在终端命令行之后输入 telnet www.shyfay.com 80 这时就进入到了telnet的命令行模式了
    然后再在命令行输入以下内容
    GET /domain/getDomain HTTP/1.1
    Host: www.shyfay.com
    然后敲入回车（换行符），这时就会向www.shyfay.com发起一个http的get请求，并且控制台会显示出www.shyfay.com这个站点响应的http内容
007.Wireshark抓包工具的安装：http://www.downxia.com/downinfo/239804.html
008.OSI （Open System Interconnection Reference Model） 概念模型，就是传统说的网络传输7层模型
    TCP协议是为了解决进程间的通信，在报文已经到达目标主机的情况下，把请求或访问报文发给主机的哪个进程，这是TCP协议做的事情，TCP协议主要作用在传输层，有些也会渗透到会话层
    IP协议是为了解决主机间的通信，报文在广域网（英特网）中传输，那么它的目的地是哪个主机呢，这就是IP协议的作用，IP协议只作用于网络层
    数据链路层主要是指的交换机，路由器这一层，它的工作原理是通过设备的MAC地址来确定将报文发往哪儿
    所谓的2层设备实际上就是指的数据链路层的产品，例如交换机
    3层设备基于IP报文的转发设备
    4LB，就是指在传输层的LoadBalance LB,
    7层负载均衡设备就是指Ngix ApacheTomcat
    分层设计的好处是，外层只需要与它往里最接近的那一层的交互，而不需要知道与它打交道的那一层的具体实现，这种分层的好处是显而易见的，就比如上层的HTTP协议从HTTP/0.9
    升级到现在的HTTP/2.0实际上做了许多许多的修改，但是内层的物理层，数据链路层确没有任何改变，如果要改变的话想象一下把全世界的交换机都换掉那代价是不是太大了。
    分层也有坏处，就是会导致网络延迟，有性能问题
009.使用HTTP协议，数据在网络数据传输7层模型中经过了哪些处理呢
    在物理层传输的是最后的bit流 我们将在这一层传输的数据为Bit  形如01010101110000101
    在数据链路层传输的数据是在IP层（网络层）传过来的数据的头部或尾部添加上一个Mac地址信息，在这一层传输的数据我们称之为Frame 形如 MAC TCP+IP+DATA FCS+
    在IP层传输的数据数据是在TCP层（传输层）传过来的数据的头部加上IP信息 在这一层传输的数据我们称之为Packet 形如 IP TCP+DATA
    TCP层传输的数据是在上层传过来的数据头部加上TCP信息 在这一层传输的数据我们称之为Sequence/Datagram 形如 TCP DATA
    更上层的数据就是HTTP或者HTTPS协议的原始数据，
010.Wireshark中的分层信息含义
    -Frame 注意这并不是数据链路层那个Freame而是有Wireshark自己生成的一些抓取信息，例如抓取时间，从哪个Mac地址抓取的等
    -Ethernet 就是对应009的Frame
    -Internet 就是对应的009的Packet
    -Transmission 就是对应的009的Sequence/Datagam
    -Transport Layer Security 就是表示的是表示层和会话层（注意这一层看不到具体的头部，因为这一层加了密）
    -HyperText Transfer Protocal 就是应用程（HTTP）
011.评估WEB架构的关键属性
    1.性能Performance 影响可用的关键因素
      网络性能（吞吐量、开销）
      用户感知到的性能（）
      网络效率
    2.可伸缩性Scalability 支持部署可以互相交互的大量组件
    3.简单性 Simplicity 易理解、易实现、易验证
    4.可见性 Visibale 对两个组件之间的监护进行监视或者仲裁的能力。如缓存分层设计等
    5.可以移植性 Portability 在不同的环境下运行的能力
    6.可靠性 Reliability 出现故障部分时，对整理服务的影响程度
    7.可修改性 Modifiability 对系统做出修改的难易程度，由可进化性、可定制性、可扩展性、可配置性、可重用性
012.五类架构风格
    平时编码时有特定的习惯，往上一级针对面向对象有设计模式，再往上就是架构
    数据流风格 Data-flow Styles  例如HTTP协议的数据流，有点是：简单性、可进化性、可扩展性、可配置性、可重用性
    复制风格 Replication Styles 例如现在的集群，优点是：用户可察觉的性能、可伸缩性、网络效率、可靠性
    分层风格 Hierarchical Styles 例如网络传输的7层模型 简单性、可进化性、可伸缩性Scalability
    移动代码风格 Mobile Code Styles 例如现在的JavaScript这种在客户端执行的脚本语言 可移植性、可扩展性、网络效率
    点对点风格 Peer-to-Peer Styles 例如FTP传输协议 可进化性、可扩展性、可配置性、可重用性
013.数据流风格
    最常见的数据流风格就是管道与过滤器Pipe And Filter, PF 型如 Pump -> Filter1 -> Filter2 -> Filtern -> Sink
    这整个就是一个水管管道，从Pump（泵）开始，中间经过多个Filter（过滤器），最后到达Sink（出口）
    一般而言一个过滤器只连接着另一个过滤器，而有些复杂的管道设计会设计成有些过滤器会连接着多个其他的过滤器
    最典型的应用场景就是网络传输的7层模型，最外层的Http协议就是Pump 最里层的物理层Bit就是Sink，儿中间的TCP/IP等都是Filter过滤器
    如果所有的过滤器的接口都是统一的，那么就是统一接口的管道与过滤器 Uniform Pipe And Filter, UPF 设计成统一接口之后系统整理的简单性会增加许多
    由于是单向和统一接口的，因此相对比较简单（简单性）
    每一个Filter都可以独自的升级进化，而不会影响到其他的Filter（可进化性）
    可以灵活的增加或者移除Filter（可扩展性，可配置性）
    Filter可以拿到其他系统去使用（可重用性）
014.复制风格
    复制风格又分为复制仓库和缓存 Replication Repository
    复制仓库通过运行多个进程的副本来提升整理的性能和可用性（例如集群，MySql的冷热备份）
    缓存，浏览器缓存，服务器缓存等等 $
    显而易见对于复制风格而言，性能、可伸缩性、可靠性都是很好的，使用缓存能够减少网络请求，网络效率也会提升
015.分层风格
    -客户端-服务器Client-Server CS 分为客户端和服务器端两层
     由Client触发请求，Server监听到请求后产生响应，Client一直等待相应结束后，会话结束
     分离关注点隐藏细节（即客户端只关心数据的获取和展示，服务器端只关心数据的处理和输出），良好的简单性、可伸缩性、可进化性
    -分层系统Layered System LS
     每一层为其上层服务。并使用在其之下层所提供的服务，例如TCP/IP
    -分层的客户端服务器架构 Layered Client-Server, LCS LS + CS
     例如正向代理和反向代理， 从空间上分为外部层与内部层
    -无状态的、客户端服务器Client-Stateless-Server CSS
     基于CS，服务器上不允许有session state会话状态
     提升了可见性，可伸缩性，可靠性，但重复数据导致降低网络性能
    -缓存，无状态，客户端服务器Client-Cache-Stateless-Server C$SS
     提升了CSS的性能
    -分层，缓存，无状态，客户端服务器Layered-Client-Cache-Stateless-Server, LC$SS
016.移动代码风格
    -虚拟机Virtual Machine,VM
     分离指令与实现
    -远程求职 Remote Evaluationm, REV
     基于CS的VM，将代码发送到服务器执行
    -按需代码Code On Demand, COD
     JavaScript 
     服务器在响应中发回处理代码，在客户端执行
     优秀的可扩展性和可配置性，提升用户可察觉性和网络效率
    -分层、按需代码、缓存、无状态、客户端服务器 Layered-Code-on-Demand-Client-Cache-Stateless-Server, LCODC$SS
     LC$SS + Code
    -移动代理Mobile Agent, MA
     相当于REV + COD
017.点对点风格
    -Event-based Integration, EBI:
     .基于事件的集成系统，比如KAFKA这样的消息系统+发布订阅来消除耦合
     .优秀的可重用性、可扩展性、可进化性
     .缺乏可理解性
     .由于消息广播等造成的消息风暴，可伸缩性差
018.REST架构，就是LCODC$SS + U(uniform interface，统一接口，网关)
019.Chrome Network
    Preserve log 在请求列表里保存之前页面的请求
    Disable cache 清除缓存请求（即将那些直接从缓存获取数据的请求从请求列表中清除）
    Offline 模拟没有网络的情况
    Online 里可以模拟弱网环境，
    在Filter输入框内可以输入 domain: method: 等等进行过滤
    将请求数据复制到剪贴板
     。Copy Link Address 复制请求网址
     。Copy Response 复制响应包体
     。Copy as cURL 以curl命令的形式复制请求网址
    查看请求上下游
     。按住shift键悬停鼠标在请求上，绿色是上游，红色是下游
020.URI与URL
    URI 统一资源标识 
    URL 资源定位
    URN 资源统一的别名
    URI 是 URL 和 URN的合集
    为什么要对URI进行编码
    在数据传递过程中，处理用作分隔符的保留字
     。例如https://www.baidu.com/s?wd=?#!
     。https://www.baidu.com/s?wd=呵呵 > 哈哈
    对可能产生歧义的数据进行编码
     。不再ASCII码范围内的字符，如中文
     。ASCII码中不可显示的字符
     。URI中规定的保留字符
     。不安全字符（传输过程中可能被不正确的处理，）如空格，引号，尖括号等
    百分号编码方式即平常经常用到的URLEncoding的编码方式是
    使用% + 字符对应的ASCII两位16进制数来标识
    对于非ASCII码字符（例如中文）：建议先进行UTF-8编码，然后再US-ASCII编码
    对于URI合法字符，编码与不编码是等价的
    例如 https://www.baidu.com/s?wd=呵呵 这个URL经过百分号编码以后就是：https%3A%2F%2Fwww.baidu.com%2Fs%3Fwd%3D%E5%91%B5%E5%91%B5
021.HTTP协议的常用方法
    GET 主要的获取信息的方法，大量的性能优化都是针对此方法，幂等方法
    HEAD 类似于GET方法，这个方法只用于获取响应头部，服务器端不会反回包体，幂等方法
    POST 常用于提交表单、新增资源、文件上传等
    PUT 更新资源，带条件时是幂等方法
    DELETE 删除资源，幂等方法
    CONNECT 建立tunnel隧道
    OPTIONS 显示服务器对访问资源支持的方法，幂等方法（常用于跨域访问的场景）
    例如在linux系统下使用curl: curl static.taohui.tech -X OPTIONS -I ，返回里面有一个Allow头部，里面的内容就是允许的方法 -X 表情请求的方法， -I表示在结果集中显示响应头
    TRACE 回显服务器收到的请求，用于定位问题。
022.用于文档管理的WEBDEV方法 （WEBDEV就是文档管理系统）
    PROPFIND 从WEB资源中检索以XML格式存储的属性，它也被重载，允许一个检索远程系统的集合结构（就是检索一个目录，一般目录是一个树状结构体，就是用XML形式返回）
    PROPPATCH 在单个原子性动作中更改或删除资源的多个属性（例如文件名称）
    MKCOL 创建集合或者目录
    COPY 将资源从一个URI复制到另一个URI
    MOVE 将资源从一个URI移动到另一个URI
    LOCK 锁定一个资源，WebDev支持共享锁和互斥锁
    UNLOCK 解锁一个资源
023.使用Nginx搭建一个WebDev的服务器，并使用WinSCP进行连接，选择WebDev协议进行远程操作
    在Wireshark中可以使用http.host==www.shyfay.com来过滤请求列表的结果集
024.HTTP协议的正确响应码
    1xx：请求已经被服务器收到，但是服务器需要做进一步处理才能完成，HTTP1.0不支持
      100 Continue：上传大文件前使用（比如迅雷）,由客户端发起请求中携带Expect: 100-continue 头部触发
      101 Switch Protocals: 协议升级使用，客户端在请求头中带上一个Upgrade头部，告知服务器说我支持websocket和heep/2.0，如果服务器端也支持高级协议，那么就会在响应头里返回会一个101告诉客户端支持高级协议
      102 Processing: WebDEV请求可能包含许多涉及文件操作的子请求，需要很长时间才能请求完成。带代码表示服务器已经收到请求并正在处理请求，但无响应可用。这样可以防止客户端超时。
    2xx：成功处理请求
        200 OK: 成功
        201 Created: 有新的资源在服务器端成功创建
        202 Accepted: 服务器端接收到请求并正在处理，但是请求处理还未完成。这样一个模糊的概念是有意设计如此，可以覆盖更多的场景，例如异步、需要长时间处理的任务。、
        203 Non-Authoritative Information: 当代理服务器修改了origin server的原始响应包体（例如更改了HTML中的元素值），
            代理服务器可以修改200为203的方式告知客户端这一事实，方便客户端对这一行为做处理，203响应可以被缓存
        204 No Content: 成功执行了请求但是响应里并不携带包体，暗示客户端无序刷新当前视图页面
        205 Reset Content: 类似于204但是要求客户端刷新页面
        206 Partial Content: 使用Rang协议时返回部分响应内容时的响应码
        207 Multi-Status: 在WEBDEV协议中以XML返回多个资源的状态（比如去访问一个目录，目录下所有的子目录都用一个XML节点表示，每一个节点都有一个HTTP/1.1 200 OK 响应码）。
            在Wireshark中可以使用http.response.code=207来过滤特定的响应码的请求
        208 Already Reported: 为避免相同集合下资源在207响应码下重复上报，使用208可以使用父集合的响应码。
    3xx：表示客户端需要进行重定向，重定向使用响应头里的Location头部指向的资源或者缓存中的资源。在RFC2068中规定客户端重定向的次数不能超过5次，以防止死循环。
        300 Multiple Choices: 资源有多重表述，通过300返回给客户端后由其自行选择哪一种表述。由于缺乏明确细节300很少使用
        301 Moved Permancetly: 资源永久性的重定向到另一个URI中
        302 Found: 资源临时的重定向到另一个URI中
        303 See Other: 重定向到其他资源，常用于POST/PUT等方法的响应中
        304 Not Modified: 当客户端拥有可能过期的缓存时，会携带缓存的标识etag和时间等信息询问服务器缓存资源是否仍然可以复用，304是告诉客户端可以复用缓存资源
        307 Temporary Redirect: 类似302，但是明确重定向后请求方法必须与原来的请求方法相，不得改变
        308 Permanent Redirect: 类似301，但是明确重定向后请求方法必须与原来的请求方法相，不得改变
025.HTTP协议的错误响应码
    4xx：表示客户端出现错误
        400 Bad Request: 服务器认为客户端出现了错误，但是不能明确判断到底是出了以下哪种错误。例如HTTP请求格式错误
        401 Unauthorized： 用户认证信息缺失或者不正确
        407 Porxy Authentication Required: 对需要经过代理的请求，认证信息未通过代理服务器的验证
        403 Forbidden：服务器理解请求的含义，但是没有权限执行此请求
        404 Not Found：服务器没有找到对应的资源
        410 Gone: 服务器没有找到对应的资源，且明确的知道在该位置永远都找不到该资源
        405 Method Not Allowed：表示服务器不支持请求的方法  使用 curl www.sina.com.cn -X TRACE -I
        406 Not Acceptable：对客户端指定的资源表述不存在（例如对语言或者编码有要求），服务器返回列表提供给客户选择
        408 Conflict： 资源冲突，例如上传文件时目标位置已经存在了版本更新的资源
        411 Length Required 如果请求含有包体但是没有携带Content-Length头部，且不属于Chunk类请求时，返回411
        412 Precondition Faild： 复用缓存时传递的If-Unmodified-Since或If-None-Match头部不被满足
        413 Payload Too Large/Request Entity Too Large：请求的包体超过了服务器能处理的最大长度
        414 URI Too Long: 请求的URI超过了服务器能接受的最大长度
        415 Unsupported Media Type: 上传的文件类型不被服务器支持
        416 Range Not Satisfiable 无法提供Range请求中指定的那段包体
        417 Expectation Faild: 对于Expect请求头部期待的情况无法满足的情况
        421 Misdirected Request: 服务器认为这个请求不应该发给它
        426 Upgrade Required: 服务器拒绝基于当前的HTTP协议系统服务，通过Upgrade头部告知客户端必须以更新的协议发起请求
        428 Precondition Required: 用户请求中缺了条件类头部，例如If-Match （主要是针对条件请求）
        429 Too Many Requests: 客户端发送请求的速率太快，一般不会发送429，一般都是发送503
        431  Request Header Fields Too Large: 请求的Header超过大小限制
        451 Unavailable For Legal Reasons: 由于法律原因资源不可访问
    5xx: 表示服务器端出现了错误
        500 Internal Server Error: 服务器内部错误，且不属于以下类型的错误
        501 Not Implemented: 服务器不支持实现请求所需要的功能
        502 Bad Gateway: 代理服务器无法获取到响应，代理服务器没办法从原服务器获取到响应，例如使用Nginx时这是很常见的
        503 Service Unavailable: 服务器资源尚未准备好处理当前的请求，比如tomcat在启动的时候访问网站就会出现503，
            遗留问题：服务器端做请求的限速，或者服务端对特定IP的并发限制等。
        504 Gateway timeout：代理服务器无法及时从上游获得响应
        505 HTTP Version Not Supported：请求使用HTTP协议版本不支持
        507 Insufficient Storage: 服务器没有足够的空间处理请求
        508 Loop Detected: 访问资源时检测到循环
        511 Network Authentication Required:代理服务器发现客户端需要进行身份验证才能获得网络访问权限
026.从TCP层面查看一个短连接的流程
    1.服务器端创建socket（调用socket方法）
    2.服务器端将socket绑定到特定的端口（调用bind方法）
    3.服务器端开启端口的监听（调用listen方法）
    4.服务器端等待来接（调用accepet方法）
    5.客户端通过DNC服务节解析域名获取服务器端的IP和端口号
    6.客户端创建新的socket
    7.客户端尝试与服务器端进行TCP的三次握手建立连接
    8.服务器端通知应用程序有连接到来，并调用socket的read方法等待连接的到来
    9.客户端连接成功
    10.客户端发起HTTP请求（调用socket的write方法）
    11.客户端调用等待服务器端的应答（调用socket的read方法，read方法是阻塞方法）
    12.服务器端的socket的read方法接受到HTTP请求，
    13.服务器端处理接受到的请求报文
    14.服务器端回送HTTP响应（调用socket的write方法）
    15.服务器端关闭连接（调用socket的close方法）
    16.客户端收到服务器端的HTTP响应并处理
    17.关闭连接（调用socket的close方法）
027.短连接与长连接
    长连接是建立起一个TCP连接后，在这TCP连接期间进行多次HTTP请求
    客户端在发起HTTP请求时如果使用了Connection: Keep-Alive头部，并且值为Keep-Alive就是建立的长连接，在HTTP/1.1中默认发送的HTTP请求就是长连接请求，因此不用显示的加上Connection: Keep-Alive头部
    Connection: Close 表示服务器不支持长连接（一般是一些很古老的服务器）
    Connection头部除了代表长连接与短连接以外，还有一个作用就是告诉代理服务器不要转发Connection列出的头部
    意思就是只针对当前连接是Connection头部指定的连接类型，形如Client -> Proxy1 -> Proxy2 -> Origin Server Client带了Connection: Keep-Alive这个头部，但是它只表示 Client与Proxy1是建立长连接的，
    Proxy1与Proxy2之间建立的可能是短连接。
    现在假设Client -> Proxy -> Origin Server Client 假设Client带了一个头部Connection:Keep-Alive，但是Proxy是一个非常非常古老的代理服务器，它根本就不认识Connection这个头部也不支持长连接，于是它就会将
    Connection:Keep-Alive这个头部转发，转发给Origin Server ,而Origin Server支持长连接，于是又给Proxy返回了一个Connection:Keep-Alive头部，然后Proxy转发给了Client，这时Client以为建立的是长连接，
    于是按照长连接的方式发起后面的HTTO请求，从而导致错误
    为了避免发生这种情况就诞生了一个新的头部Proxy-Connection:对于陈旧的代理服务器不认识该头部，这时Client和Origin Server都采用短连接，而新的代理服务器认识Proxy-Connection于是建立长连接
028.Host头部
    HTTP/1.1要求请求必须要携带Host头部，而且只能携带一个Host头部
    服务器处理HTTP请求的步骤如下
    1.建立TCP连接
    2.接受请求
    3.寻找虚拟主机（匹配Host头部或者域名,）
    4.寻找URI的处理代码（匹配Path和参数等信息）
    5.执行处理请求的代码
    6.生成Http响应
    7.发送http响应
    8.记录访问日志并关闭连接
029.代理服务器转发消息的相关头部
    RFC规范中使用X-Forwarded-For 头部用于在代理服务器之间传递用户真实的外网IP
    也有一些非官方的例如Nginx就会使用X-Real-IP这个头部用于传递用户的真实外网IP
    Max-Forwards 限制代理服务器最多转发N次。仅对TRACE/OPTIONS方法有效
    Via头部 指明经过代理服务器的名称和版本
    Cache-Control：no-transform 禁止代理服务器修改包体
030.表示上下文的头部（所谓上下文就是指请求从哪里来，或者请求对于后面的请求会产生哪些影响）
    User-Agent 指明客户端的类型信息，服务器可以据此对资源的表述做抉择，例如： Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36
    包含3个部分  Mozilla/5.0 (Windows NT 6.1; WOW64)表示浏览器遵循的规则，注释 AppleWebKit/537.36(KHTML, like Gecko)是浏览器采用的渲染引擎，Chrome/67.0.3396.99 Safari/537.36表示浏览器类型和版本 ，括号内的内容是注释
    Referer 浏览器对来自某一页面的请求自动添加的头部 比如在百度里搜索新浪微博，然后我们点击新浪微博的连接时的第一个请求的请求头里就包含了Referer: https://www.baidu.com
    Referer的作用是：服务器常用于统计分析，缓存优化，防盗链等（所谓的防盗链的意思就是有些资源例如图片不希望被别的站点直接引用）
    From 主要用于网络爬虫，告诉服务器如何通过邮件联系到爬虫的负责人
    Server 指明服务器上所使用的软件信息，用户客户端定位问题或者同级分析
    Allow 告诉客户端，服务器上该URI对应的资源允许哪些方法访问 例如Allow: GET,HEAD,PUT
    Accepet-Ranges: 告诉客户端服务器上该资源是否允许range请求，例如Accept-Ranges: bytes  Accept-Ranges: none
031.内容协商与资源表述使用到的Http头部（例如同一个网页中国的用户访问服务器端返回的是中文，美国的用户访问时展示的可能是英语）
    内容协商的两种方式
    Proactive主动式内容协商
    指由客户端现在请求头部提出需要的表述形，而服务器根据这个请求头部提供特定的representation表述，这样做有一个不好的地方就是服务器端可能会相对比较武断
    例如 Accept: text/* Accept-Language: en Accept-Encoding: br, gzip; q=0.8
    Reactive 响应式内容协商 指服务器返回300 Multiple Choices 或者406 Not Acceptable 由客户端选择一种表述方式，RFC没有一个规范来约束浏览器到底应该怎么选择服务器端返回的资源中的哪一种，因此很少使用到
    常见的协商要素
     -质量因子 q：
       1.它表示内容的质量，比如传输一张图片，如果浏览器只希望展示一张缩略图那么质量因子可以设置得小一点，如果浏览器端希望展示的是高清大图，就可以把质量因子设置得大一点
       2.可接受类型的优先级等，比如网页接受简体中文，繁体中文，英语，但是浏览器最希望用简体中文>繁体中文>英语展示，那么就把简体中文的q设置得最大，而繁体中文次之，英文最小
     -资源的MIME类型（Accept） ：
       它表示的是浏览器希望或者服务器返回的资源的类型，例如文本，xml，base64啥的
       例如： Accept: text/*
     -字符编码（Accept-Charset）：
       它表示浏览器希望以什么编码格式来编码数据，但是由于现在UTF-8编码的广泛使用，现在很少用到这个头部了
       例如： Accept-Charset: ISO-8859-1,utf-8
     -内容编码 主要是指压缩算法（Accept-Encoding）:
       由于我们的文本格式可以有很高的压缩比，因此服务器端要告知客户端我支持哪些压缩算法
       例如Accept-Encoding: gzip,deflate,br
     -语言表述（Accept-Language）:
       表示支持或者接受哪些语言，例如Accept-Language: zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7
       internationalization(i18n, 第一个字母i最后一个字母n中间有18个字母) 是指设计软件时，在不同的国家，地区可以不做逻辑实现层面的修改就能够以不同的语言显示
       localization(l10n) 指内容协商时，根据请求中的语言及地区信息，选择特定的语言作为资源表述。
    资源表述的元数据头部（所谓元数据就是在）
    媒体类型和编码 content-type: text/html;charset=utf-8
    内容编码： content-encoding:gzip
    语言: content-language: de-DE,en-CA
    在浏览器访问百度首页，然后在把第一个请求中copy as cURL(bash) 到linux系统下使用curl命令执行，然后把最后的--compressed去掉看看会发生什么，在把--compressed去掉的情况下，把
     -H 'Accept-Encoding: gzip, deflate, br' 这一段去掉看看又会发生什么
032.定长包体
    对于定长包体而言，一定要使用Content-Length头部标明要传输的包体的字节数
    Content-Length: 后面跟包体的字节数（10进制），优点是接收端处理简单
    例如实际的包体内容是HelloWorld（10字节），但是如果把Content-Length: 6 ，这时实际上浏览器只能收到HelloW ，后面的4个字节被截断了
    如果把Content-Length: 11 那么这时浏览器将不会收到任何数据，但是响应码还是：200 OK
    发送HTTP消息时不能确定包体的全部长度
    Transfer-Encoding: chunked
    使用Transfer-Encoding头部指明使用Chunk传输方式，含有Transfer-Encoding头部后Content-Length头部会被忽略
    优点是：
        基于长连接持续推送动态内容
        压缩体积较大的包体时，不必完全压缩（计算出长度）后再发送，可以边压缩边发送
        传递必须在包体传输完才能计算出的Trailer头部，意思就是在包体完全传输完成之后再发送一个额外的http请求告诉对方完整包体的长度信息
    Chunk的body表述
    Chunk-body = *chunk    
                 last-chunk
                 trailer-part
                 CRLF
    chunk = chunk-size[chunk-ext]CRLF chunk-data CRLF
        . chunk-size = 1*HEXDIG(16进制)  这个chunk的大小
        . chunk-data = 1*OCTET (二进制流)  这个chunk的内容
    last-chunk = 1*("0")[chunk-ext]CRLF  即用一个0表示这个chunk结束
    trailer-part = *(header-field CRLF) 0个或多个trailer头部
    浏览器通过trailer: TE头部来告诉服务器端可以接受chunk类型的包体
033.MIME 包体的媒体类型
    Content-Type
    Content-Type : type/subtype *(; parameter)
    .type := discrete-type/composite-type
      .discrete-type := text/image/audio/video/application/extension-token
      .composite-type := message/multipart/extension-token
      .extension-token := ietf-token/x-token
    .subtype := extension-token/iana-token
    .parameter := attribute = value
    例如： Conent-type:text/plain;charset="utf-8";
    大小写不敏感，通常都小写
    Content-Disposition: disposition-type
    disposition-type = inline/attachment/disp-ext-type
    .inline: 指包体是以inline内联的方式作为页面的一部分展示
    .attachment: 指定浏览器将包体以附件的方式下载，例如 Content-Disposition: attachment 或者 Content-Disposition: attachment; filename="xxx.jpg"
    .在multipart/form-data类型的应答中，可以用于子消息体部分 例如 Content-Disposition: form-data; name="fieldName"; filename="xxx.jpg"