http协议

提到页面的优化,不得不提页面的请求
    于是,还得学http TCP/IP  https 缓存....
=====================================================
1.对于 TCP三次握手协议的理解
    参考:
        https://segmentfault.com/a/1190000009183220
    1.什么是TCP三次握手呢?
        双工--保证二者都是可以收发信息的
        而且是可以理解对方的消息,并且可以做出正确的应答的
    2.什么是http协议呢??
        http:超文本传输协议(HyperText Transfer Protocol )
        他是建立在TCP协议上面的一种应用
        特点:(一次连接)或者叫做短连接
            1.在1.0的时候,客户端每次请求都需要建立一次单独的连接
                在处理完之后,自动释放
            2.在http1.1中,可以一次连接处理多个请求的,多个请求可以重叠 (就是一部的意思),   
                不需要等待队列之类的运行
            3.http请求称为短连接,隔一段时间需要向服务器发送保持连接的请求
                服务器收到保持连接的请求之后,回复客户端
                长时间,收不到客户机的连接请求,则认为客户机已经下线了.
    3. socket(嵌套) 嵌套字连接
        概念:
            是支持TCP/IP协议网络通信的进本操作单元
        包括5中信息:
            1.连接使用的协议
            2.本地主机的IP地址
            3.本地进程协议端口
            4.远地主机IP端口
            5.远地进程的协议端口
        可以使用的场合:
            应 用层可以和传输层通过Socket接口，区分来自不同应用程序进程或网络连接的通信，实现数据传输的并发服务。
        建立socket连接:
            1.需要一堆套接字,其中一个运行在客户端,一个运行在服务端
            建立链接的过程:
                1.服务器的监听
                2.客户端的请求
                3.连接确认
            2.socket连接
                创建socket连接的时候,可以指定传输层协议,socket可以支持不同的传输层协议
                (TCP或者UDP)
                当使用TCP协议进行练级的时候,Socket就是一个TCP连接
            3.Socket连接和http连接
                最关键的一点---Socket协议,可以尝试键保持在线(不是短连接---长连接)
                客户端定时向服务器端发送连接请求， 不仅可以保持在线，
                同时也是在“询问”服务器是否有新的数据，
                如果有就将数据传给客户端。
                TCP(Transmission Control Protocol)　传输控制协议
                二者的区别:
                    客户端向服务器发送数据的时候:
                    此时若双方建立的是Socket连接，服务器就可以直接将数 据传送给客户端；
                    若双方建立的是HTTP连接，则服务器需要等到客户端发送一次请求后才能将数据传回给客户端，
2.http TCP socket的关系    
    必须先了解OSI的七层模型
        http在应用层的
        TCP/UDP在传输层
        
    而socket
        SOCKET 应该算不上是个协议，应该是应用层与传输层间的一个抽象层，是个编程接口。 
                
3.关于https协议
    参考:
        http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html
        https://segmentfault.com/a/1190000004523659
    为什么要是用https协议:
        1.http协议是明文传输的,中间的代理,路由可以截取和获取传输的信息
            用户登陆 --> 代理服务器（做手脚）--> 实际授权服务器
        2.https 
            secure http
            在HTTP跟TCP中间加多了一层加密层TLS/SSL==>于是就有了https
        3.关于加密过程中涉及到的密码学    
        
        4.直接看https传输的过程
            1.握手,证书的下发,秘钥的协商(这个阶段是明文的)
            2.数据的传输:这个阶段是加密的,使用握手阶段协商出来的对称秘钥
4.关于http 2.0
    参考:
        https://mp.weixin.qq.com/s/0m4R31gSV-DfY_-VOSb_jA
        懒得看,
        
5.h5的新特性(webSocket)
    参考:
    https://mp.weixin.qq.com/s/0m4R31gSV-DfY_-VOSb_jA
6.重点来了 --关于http的缓存
    参考:https://mp.weixin.qq.com/s/R3znqyYGRA9iHVbHzTEtzA
    http://www.alloyteam.com/2016/03/discussion-on-web-caching/
    
    http报文字段:
        1.通用字段(响应和接收通用的)
            1.Cache-Control
                控制缓存行为
            2.Pragma http1.0     值为 no-Cache时,禁用
            
        2.请求的字段
            if-Match
                比较ETag是否一致
            if-none-Match
                比较ETAg 是否不一致
            if-modified-Since
                比较资源的最后更新时间是否一致
            if-Unmodified-Since 
                比较资源的最后一次更新是否不一致
        3.响应的头部字段
            ETag 
                资源的匹配信息
        4.实体的首部字段
            Expires  http1.0  实体的过期时间
            Last-Modified
                实体的最后一次修改时间
7.详细讲解http关于缓存的部分
    long long ago
    1.Pragma
        Pragma:no-Cache
        告诉客户端---不要对该资源读缓存(直接请求服务器)
        使用的时候:
            <meta http-equiv="Pragma" content="no-cache">
            但是:
                仅有IE识别这段meta标签
                其他的浏览器识别的是,“Cache-Control: no-store”的meta标签（见出处）。
    2.Ecpires(该字段。用来控制缓存的失效日期)       
        Expires的值对应一个GMT（格林尼治时间），比如“Mon, 22 Jul 2002 11:12:01 GMT”来告诉浏览器资源缓存过期时间，如果还没过该时间点则不发请求。
        就是告诉浏览器,多长的时间请求一次资源
        限制:
            也仅有IE能识别
            同样也只对页面有效，对页面上的资源无效
        使用的语法:
            <meta http-equiv="expires" content="mon, 18 apr 2016 14:30:00 GMT">
            如果希望在IE下页面不走缓存，希望每次刷新页面都能发新请求，那么可以把“content”里的值写为“-1”或“0”
    3,Cache-Control
        为什么会出现?
            Expires时间是相对服务器而言，无法保证和客户端时间统一
        http1.1 新增的字段
        也是来定义缓存过期时间的,优先级最高.
        Cache-Control 来定义缓存过期时间，若报文中同时出现了 Pragma、Expires 和 Cache-Control，会以 Cache-Control 为准
        使用的格式:
            "Cache-Control" ":" cache-directive
            我们依旧可以在HTML页面加上meta标签来给请求报头加上 Cache-Control 字段：
            代码案例:
                Cache-Control: max-age=3600, must-revalidate
                意义:
                    该资源是从原服务器上取得的，且其缓存（新鲜度）的有效时间为一小时，在后续一小时内，用户重新访问该资源则无须发送请求。
    4.一系列的缓存校验字段
        1. Last-Modified(最后一次修改)
            1. If-Modified-Since: Thu, 31 Mar 2016 07:07:52 GMT
                告诉服务器客户端传来的最后修改时间与服务器的一致===304
            2. If-Unmodified-Since: Last-Modified-value
                告诉服务器,Last-Modified没有匹配上（资源在服务端的最后更新时间改变了），则应当返回412(Precondition Failed) 状态码给客户端
                    如果,服务器的资源修改了,Last-Modified时间不匹配
                    就会返回整个实体资源给客户端的
        
        2.ETag
            为什么会出现??
                服务器的资源只是修改了路径,但是没有修改资源的内容
                于是,http1.1 推出了Etag
            什么是Etag
                给资源一个唯一的标识(就是MD5的值)
            如何运作:
                服务器将ETag标识,返回给客户端
                客户端再次请求的时候,带着这个ETag值,去服务器的匹配一下子
                如果是一致的:
                    返回304 读取缓存
                如果不一致:
                    返回200 ,携带着新的资源
            在请求的报文中,有两个头部的字段可以带上ETag值的
                1. If-None-Match: "56fcccc8-1699"
                    告诉服务器,Etag没有匹配上,需要重发资源数据
                2. If-Match: ETag-value
                    告诉服务器如果没有匹配到ETag，或者收到了“*”值而当前并没有该资源实体，
                    则应当返回412(Precondition Failed) 状态码给客户端。
                    否则服务器直接忽略该字段
8.一些其他的头部字段的解释: 
    1.Vary (变化)
        Vary: User-Agent
        服务器根据Vary的User-Agent 请求头部来判断需要在页面缓存的版本
        Vary: User-Agent, Accept-Encoding的写法,也是可以的
    2.Date和Age
        Data:日期
            显示服务器发送该资源的时间
            如果,这个时间与当前的时间差别比较大或者F5刷新,Data的值没有变化
            没错,你是用的是缓存
        Age:
            Age 也是响应报文中的首部字段，它表示该文件在代理服务器中存在的时间（秒）
            文件在代理服务器中存在的时间
            文件的修改和替换会导致Age从0开始累计
    3.有一个计算的公式
        静态资源Age + 静态资源Date = 原服务端Date
            
=================================
web的缓存机制:看这里...
    http://www.alloyteam.com/2016/03/discussion-on-web-caching/