http & https & http2.0

一.http状态码

  1. 1xx(信息性状态码,接受的请求正在处理)
  2. 2xx(成功状态码,请求正常处理完毕)
    200 OK
    204 No Content:请求成功但没有资源返回
    206 Partial Content:范围请求
  3. 3xx(重定向状态码,需要进行附加操作以完成请求)
    301 Moved Permanently:永久性重定向()
    302 Found:临时性重定向
    303 See Other:同302,用GET获取资源
    304 Not Modified: 内容没有改,响应不包含主体部分
           (请求头If-None-Match对应响应头Etag,请求头If-Modified-Since对应响应头Last-Modified)
    307 Temporary Redirect:同302
  4. 4xx(客户端错误状态码,服务器无法处理请求)
    400 Bad Request:请求报文存在语法错误
    401 Unanuthority:请求需要通过认证,若之前以请求过1次,表示认证失败
    403 Forbidden:不允许访问
    404 Not Found:服务器无请求资源
  5. 5xx(服务端错误状态码,服务器处理请求出错)
    500 Internal Server Error:服务器在执行请求是发生错误
    503 Service Unavailable:现在在忙无法处理请求
  6. 301和302状态码都是浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的url,这个url可以从响应的Location头部中获取(用户看到的效果就是他输入的地址A瞬间变成了另一个地址B)。区别在于301表示旧地址A的资源已经被永久地移除了(这个资源不可访问了),搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址;302表示旧地址A的资源还在(仍然可以访问),这个重定向只是临时地从旧地址A跳转到地址B,搜索引擎会抓取新的内容而保存旧的网址。
    302可能会导致url被劫持。

二. http与https

  1. http不足:

    通信使用明文(不加密),内容可能会被窃听;
    不验证通信方的身份,因此有可能遭遇伪装;
    无法证明报文的完整性,所以有可能已遭篡改;

  2. https(用SSL建立安全通信线路之后,就可以在这条路上进行http通信了):
    https = http + 加密 + 认证 + 完整性保护
  3. SSL 不仅提供加密处理,而且还使用了一种被称为证书的手段,可用于确定通信方的身份;
    SSL采用公开密钥加密,非对称的密钥(私有密钥和公开密钥),发送方使用对方的公开密钥进行加密,对方再用自己的私有密钥解密;
  4. https采用混合加密机制,公开密钥加密相比于共享密钥加密处理速度要慢;
    ① 使用公开密钥加密方式安全地交换在稍后的共享密钥加密中要使用的密钥,
    ② 确保交换的密钥是安全的前提下,使用共享密钥加密方式进行通信;
  5. https提供了对服务器的身份认证,保护交换数据的隐私和完整性,针对http的问题,https解决方案:数据加密、客户端服务端都携带证书,对数据进行摘要处理(即使改也没用);
  6. https工作原理:
     [ 1 ] 客户端给出协议的版本号、一个客户端生成的随机数和客户端支持的加密算法;
     [ 2 ] 服务端在客户端给出的加密算法列表中选出一种,并给出数字证书和一个服务端生成的额随机数;
     [ 3 ] 客户端确认数字证书的有效性,然后生成一个新的随机数,并使用数字证书中的公钥加密这个随机数;
     [ 4 ] 服务端使用私钥解密,获取客户端发来的随机数;
     [ 5 ] 客户端和服务端根据约定的加密方法,使用之前的三个随机数,生成对话密钥,这个密钥会用来加密接下来的整个通信过程
  7. https不足:握手费时,证书费钱,https连接缓存不如http高效,加密范围有限,解密慢;
  8. https协议原理:
    [1]客户端请求(带有客户端支持的加密算法列表,随机数A)
    [2]服务器端比对支持的加密算法,选出最合适的加密算法 
    [3]响应(加密算法 公钥 证书 随机数B)
    [4]客户端去验证证书的有效性,生成一个随机字符串pre-master,再根据A B p re-master计算出协商秘钥
    [5]请求(使用公钥加密pre-master使用协商秘钥加密的数据)
    [6]服务器端用私钥解密得到pre-master,使用协商秘钥解密数据
    [7]响应(告知客户端,以后通信就用协商秘钥加密)

三. http1.0 vs http1.1

  1. http1.1支持长连接;
  2. HTTP 1.0规定浏览器与服务器只保持短暂的连接,浏览器的每次请求都需要与服务器建立一个TCP连接,服务器完成请求处理后立即断开TCP连接,服务器不跟踪每个客户也不记录过去的请求。
  3. HTTP 1.1则支持持久连接Persistent Connection, 并且默认使用persistent connection. 在同一个tcp的连接中可以传送多个HTTP请求和响应. 多个请求和响应可以重叠,多个请求和响应可以同时进行. 更加多的请求头和响应头(比如HTTP1.0没有host的字段).
  4. 缓存处理
  5. 增加一些错误状态码;

四. http2.0 vs http 1.1

  1. 多路复用允许单一的 HTTP/2 连接同时发起多重的请求-响应消息
  2. 二进制分帧层 在 应用层(HTTP/2)和传输层(TCP or UDP)之间。HTTP/2并没有去修改TCP协议而是尽可能的利用TCP的特性
  3. 单连接多资源的方式,减少服务端的链接压力,内存占用更少,连接吞吐量更大;由于减少TCP 慢启动时间,提高传输的速度
  4. 首部压缩
  5. HTTP2支持服务器推送

五. 三次握手

  1. syn=j --> ack=j+1 syn=k --> ack=k+1 (三次握手)

六. 四次挥手

  1. tcp客户端发送一个fin,用来关闭客户端到服务器的传送(fin=1 ack=z seq=x)
  2. 服务器收到fin,发回一个ack,确认序号为收到序号加1,和syn一样,一个fin占用一个序号(ack=x+1 seq=z)
  3. 服务器关闭客户端连接,发送fin(fin=1 ack=x seq=y)
  4. 客户端发回ack确认,并将确认序号设为收到序号加1(ack=y seq=x )

七. tcp / udp

  1. 面向连接的tcp和面向非连接的udp
  2. tcp可靠稳定,数据传送完断开连接节约资源,大量数据,缺点是慢,应用http、ftp
  3. udp快,少量数据,不可靠,网络不好容易丢包,应用qq、长视频

八. ws

  1. ajax轮询:每隔几秒发送请求一次
  2. long pull:也是轮询,不过是阻塞模型
  3. ws是右http建立连接,全双工通道,实现持久化

九. spdy

  1. 多路复用降低了延迟同时提高了带宽的利用率;
  2. 每个请求设置请求优先级防止重要请求被阻塞;
  3. header压缩;
  4. 基于https;
  5. 服务端推送;
  6. http-> spdy -> ssl -> tcp

十. spdy vs http2.0

  1. http2.0 支持明文 HTTP 传输,而 SPDY 强制使用 HTTPS
  2. http2.0 消息头的压缩算法采用 HPACK,而非 SPDY 采用的 DEFLATE

十一. tcp粘包拆包问题

  • 由于tcp是以流动的方式传输数据,传输的最小单位为一个报文段(segment)。tcp Header中有个Options标识位,常见的标识为mss(Maximum Segment Size)指的是,连接层每次传输的数据有个最大限制MTU(Maximum Transmission Unit),一般是1500比特,超过这个量要分成多个报文段,mss则是这个最大限制减去TCP的header,光是要传输的数据的大小,一般为1460比特。换算成字节,也就是180多字节。
    tcp为提高性能,发送端会将需要发送的数据发送到缓冲区,等待缓冲区满了之后,再将缓冲中的数据发送到接收方。同理,接收方也有缓冲区这样的机制,来接收数据
  1. 应用程序写入的数据大于套接字缓冲区大小,这将会发生拆包。
  2. 应用程序写入数据小于套接字缓冲区大小,网卡将应用多次写入的数据发送到网络上,这将会发生粘包。
  3. 进行mss(最大报文长度)大小的TCP分段,当TCP报文长度-TCP头部长度>mss的时候将发生拆包。
  4. 接收方法不及时读取套接字缓冲区数据,这将发生粘包。
  • 由于tcp是无界的数据流,且协议本身无法避免粘包,拆包的发生,那我们只能在应用层数据协议上,加以控制。通常在制定传输数据时,可以使用如下方法:

  1. 使用带消息头的协议、消息头存储消息开始标识及消息长度信息,服务端获取消息头的时候解析出消息长度,然后向后读取该长度的内容。
  2. 设置定长消息,服务端每次读取既定长度的内容作为一条完整消息。
  3. 设置消息边界,服务端从网络流中按消息编辑分离出消息内容。
posted @ 2017-09-28 10:27  we are young  阅读(1548)  评论(1编辑  收藏  举报