图解HTTP读书笔记

HTTP

HTTP特性

HTTP 是一个属于应用层的面向对象的协议，HTTP 协议一共有五大特点：1、支持客户/服务器模式；2、简单快速；3、灵活；4、无连接；5、无状态。

特性解读

客户/服务器模式, 请求/响应模式
简单快速
客户向服务器请求服务时，只需传送请求方法和路径。

灵活
HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。

无连接 TCP连接是否断开，HTTP/1.0之后的版本默认为持久连接
限制每次连接只处理一个请求。请求时建连接、请求完释放连接，以尽快将资源释放出来服务其他客户端。容量小时，可节省传输时间。容量大时，则会增加通信量的开销，使得传输效率降低。

持久连接-Keep alive
只要任意一端没有明确提出断开连接，则保持TCP连接状态。在建立连接后可进行多次请求与响应
管线化 pipelining
keep-alive使得pipelining成为可能,可同时并行发送多个请求

无状态 stateless
HTTP是一种不保存状态，即无状态协议，不对请求和响应之间的通信状态进行保存。HHTP协议的每个请求都是独立的，Keep-Alive 没能改变这个结果。

由此有状态管理: Cookie session
使用cookie状态管理
cookie机制采用的是在客户端保持状态的方案.
使用 session 状态管理
session机制采用的是在服务器端保持状态的方案，典型的场景比如购物车。Tomcat中将session叫jsession

JSESSIONID和sessionid的区别

Cookie vs Session

Cookie

    包含用户信息和计算机浏览器信息,根据生命期不同分成两种：会话cookie和持久cookie；会话cookie保存在内存里，浏览器退出即消失。持久cookie为硬盘cookie，设置了过期时间，在过期时间内，存储在硬盘上的cookie可以在不同的浏览器进程间共享。
    故根据硬件分类，又分为内存cookie和硬盘cookie，主要用于解决HTTP无状态、无法实现交互式web应用程序的问题，服务器读取cookie，维护用户和服务器会话的状态。Cookie具有不可跨域名性。
    主要用途：会话状态管理、个性化设置、浏览器行为跟踪跨站点脚本攻击，cookie盗贼（搜集用户cookie）和cookie投毒（修改传入服务器的cookie）

session

    第一次创建Session的时候，服务端会在HTTP协议中告诉客户端，需要在 Cookie 里面记录一个Session ID，以后每次请求把这个会话ID发送到服务器。Session就是一种保存上下文信息的机制，它是针对每一个用户的，变量的值保存在服务器端，通过SessionID来区分不同的客户，Session是以Cookie或URL重写为基础的，默认使用Cookie来实现，系统会创造一个名为JSESSIONID的输出Cookie，我们叫Session Cookie,以区别Persistent cookies,也就是我们通常所说的cookie。注意session cookie是存储于浏览器内存中的，并不是写到硬盘上的，即JSESSIONID，通常是看不到JSESSIONID的。
   虽然Session保存在服务器，对客户端是透明的，它的正常运行仍然需要客户端浏览器的支持。这是因为Session需要使用Cookie作为识别标志。HTTP协议是无状态的，Session不能依据HTTP连接来判断是否为同一客户，因此服务器向客户端浏览器发送一个名为JSESSIONID的Cookie，它的值为该Session的id（也就是HttpSession.getId()的返回值）。Session依据该Cookie来识别是否为同一用户。
   只有访问JSP、Servlet等程序时才会创建Session，只访问HTML、IMAGE等静态资源并不会创建Session。
    禁用cookie后，利用URL重写重写技术，就是把session id直接附加在URL路径的后面。还有一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。

cookie & session

Cookie是客户端保存用户信息的一种机制，用来记录用户的一些信息，也是实现Session的一种方式。cookie携带session id后，到服务端session做验证。
1、cookie数据存放在客户的浏览器上，session数据放在服务器上。
2、cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗，考虑到安全应当使用session。
3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，考虑到减轻服务器性能方面，应当使用COOKIE。
4、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。
5、所以个人建议：
   将登陆信息等重要信息存放为SESSION
   其他信息如果需要保留，可以放在COOKIE中

防session id窃取方案

窃取途径：XSS（恶意代码）、CSRF（钓鱼网站），攻击防御
防窃取方案：cookie不存放敏感信息和用户不应知道的信息，只存放session id

    设置HttpOnly属性防止XSS攻击。在PHP中，可以通过修改php.ini中的“session.cookie_httponly = 1 ”开启全局Cookie的HttpOnly属性。也可以使用“setcookie”函数来启用。
    客户端发生变化时，要求用户重新登录。例如使用User-Agent、IP地址、MAC地址等检测请求的一致性,并且加入Token进行检验。
    更改SessionID名称。例如PHP中SessionID的默认名称是PHPSESSID，此变量会保存在Cookie中，如果攻击者不分析站点，就不能猜到SessionID的名称，阻挡部分攻击。加大SessionID的安全长度，加大暴力猜解难度。
    为每一次请求生成新的SessionID，特别是登陆前后的 SessionID需要有所不相同，只接受服务器生成的SessionID。
    设置会话超时属性，设定阈值强制会话过期。

参考链接：
Cookie/Session机制详解

HTTP1.0/1.1/2.0 区别

HTTP/1.0：多媒体处理，HTTP请求头支持多种请求；连接无法复用，请求分离，线头阻塞（请求无法响应，后面的请求被阻塞）。
HTTP/1.1：可扩展性、缓存处理、带宽优化、持久连接、Host头、错误通知、消息传递、内容协商等。

1. 默认持久连接（Connection: keep-alive）和流⽔水线传输（即不用等上一个响应再发下⼀个），关闭：Connection: closed；
2. 增加了请求头和响应头来扩充功能：
a. 支持Host请求；
b. Connection；
c. 支持断点续传；
d. 身份认证；
e. 状态管理；
f. Cache缓存处理。
3. 状态码100 Continue， POST时大于1024，先询问是否接收（状态码较多，部分由其它RFC定义）
4. Host 域：一台物理理主机对应多个虚拟主机->共享⼀一个ip
5. 可分块传输数据：Transfer-Encoding: chunked否则对于动态⽣生成的响应，要把响应整个缓存才知道长度，才能填写Content-Length

HTTP/2.0：把解决性能问题的方案内置在了传输层，添加二进制帧分层，通过多路复用来减少延迟，通过压缩 HTTP首部降低开销，同时增加请求优先级和服务器端推送的功能。
HTTP/2 简介

1.支持多路复用
    每个来源一个连接，多路复用允许同时通过单一的 HTTP 2.0 连接发起多重的请求-响应消息，即所有HTTP 2.0 连接都是持久化的，而且客户端与服务器之间也只需要一个连接即可，所有数据流共用同一个连接，减少了因http链接多而引起的网络拥塞（在 HTTP1.1 协议中，同一时间，浏览器会针对同一域名下的请求有一定数量限制），解决了慢启动针对突发性和短时性的http链接低效的问题。
    流控制是一种阻止发送方向接收方发送大量数据的机制，以免超出后者的需求或处理能力。
2.将通信的基本单位缩小为帧
    请求和响应复用：客户端和服务器可以将 HTTP 
    消息分解为互不依赖的帧，然后交错发送，最后再在另一端把它们重新组装起来。
    HTTP/2 中的新二进制分帧层解决了 HTTP/1.x 中存在的队首阻塞问题，也消除了并行处理和发送请求及响应时对多个连接的依赖。结果，应用速度更快、开发更简单、部署成本更低。
3.首部压缩
    HTTP/2 支持DEFLATE和HPACK 算法的压缩，经过专门设计，可以解决发现的安全问题、实现起来也更高效和简单，可以对 HTTP 标头元数据进行良好压缩。（动态索引表）
4.服务端推送
    客户端请求之前发送数据的机制，在 HTTP 2.0 中，服务器可以对客户端的一个请求发送多个响应，可推送额外的信息。
5.请求优先级
    HTTP 2.0 使用一个31比特的优先值,0表示最高优先级, 2(31)-1表示最低优先级，服务器端就可以根据优先级，控制资源分配，优先处理和返回最高优先级的请求帧给客户端。

HTTP2.0与WebSocket

HTTP 2.0服务器推送不是诸如Server-Sent Events (SSE)或WebSocket的技术替代品。通过HTTP 2.0服务器推送传递过来的资源由浏览器来处理，但却不能上升到程序代码的层面 - 因为没有JavaScript API来获取这些事件的通知。不过，解决这个难题的方法却很简单，因为我们可以把一个SSE通道和服务器推送结合起来，使两者都达到最佳效果。通过HTTP 2.0，服务器有机会变得非常非常智能，包括如何优化传送一些具体的资源，更重要的是，也包括优化对整个应用的传送。类似的，浏览器可能增加额外的API和能力来使这个过程更加高效。
在HTTP/2中，在场景后面使用服务器推送来提高客户端从浏览器加载资源的能力。作为一个开发人员，你在开发过程中并不真正关心它。但是，使用WebSocket，开发人员可以使用API，该API能够使用唯一的全双工连接来使用和推送消息。

1 补充关系 二者侧重点不同。SPDY更侧重给Web页面的加载提速，而websocket更强调为web应用提供一种双向的通信机制以及API
2 竞争关系，二者解决的问题有交集，比如在服务器上推送上SPDY和Websocket都提供了方案
3 承载关系，SPDY若标准化早于websocket，则websocket完全可以侧重于API，利用SPDY的帧机制和多路复用机制实现该API
4 融合关系，如微软在HTTP Speed+Mobility中所做

HTTP实现

HTTP在TCP/IP的通信传输流

#每通过一层都进行一次封装
 应用层 HTTP客户端 HTTP服务器   #HTTP报文  HTTP数据
        ↓          ↑            
 传输层 TCP        TCP          #TCP报文段 TCP首部
        ↓          ↑
 网络层 IP         IP           #IP数据包  IP首部
        ↓          ↑
 链路层 网络  →    网络          #网络架构 以太网首部 

各协议与HTTP协议的关系（TCP/IP DNS）

输入域名(url)-->DNS映射为IP-->TCP三次握手-->HTTP请求-->HTTP响应-->(浏览器跟踪重定向地址)-->服务器处理请求-->服务器返回一个html响应-->(视情况决定释放TCP连接)-->客户端解析HTML-->获取嵌入在HTML中的对象重新发起http请求

HTTP重定向和转发

1.实际发生位置不同，地址栏不同

• 重定向是由浏览器进行跳转的，进行重定向跳转的时候，浏览器的地址会发生变化的。实现重定向的原理是由response的状态码和Location头组合而实现的。这是由浏览器进行的页面跳转实现重定向会发出两个http请求，**request域对象是无效的，因为它不是同一个request对象
• 转发是由服务器进行跳转的，在转发的时候，浏览器的地址栏是没有发生变化的，在我访问Servlet111的时候，即使跳转到了Servlet222的页面，浏览器的地址还是Servlet111的。也就是说浏览器是不知道该跳转的动作，转发是对浏览器透明的。通过上面的转发时序图我们也可以发现，实现转发只是一次的http请求，一次转发中request和response对象都是同一个。这也解释了，为什么可以使用request作为域对象进行Servlet之间的通讯。
• 转发是发生在服务器的
• 重定向是发生在浏览器的

2.用法不同

• 重定向时"/"代表的是webapps目录
• 转发时"/"代表的是本应用程序的根目录
• 资源地址书写：给服务器用的直接从资源名开始写，给浏览器用的要把应用名写上
• request.getRequestDispatcher("/资源名 URI").forward(request,response)
• response.send("/web应用/资源名 URI");

3.能够去往的URL的范围不一样

• 转发是服务器跳转只能去往当前web应用的资源
• 重定向是服务器跳转，可以去往任何的资源

4.传递数据的类型不同

• 转发的request对象可以传递各种类型的数据，包括对象
• 重定向只能传递字符串

5.跳转的时间不同

• 转发时：执行到跳转语句时就会立刻跳转
• 重定向：整个页面执行完之后才执行跳转

HTTP请求/响应的步骤

浏览器解析和渲染(边解析边渲染)

从输入URL到页面加载发生了什么
HTML文件构建DOM树-->CSS文件构建CSSOM树-->构建渲染树和布局-->JS代码加载-->页面绘制和渲染
js代码渲染完成后html才能进行html渲染

HTTP优化

负载均衡技术、TCP连接复用（多个客户端的HTTP请求复用到一个服务器端TCP连接上）、HTTP复用（管道pipelining）、内容缓存、TCP缓冲（解决后端服务器网速与客户的前端网络速度不匹配而造成的服务器资源浪费的问题）、HTTP压缩（对客户端的响应请求进行压缩处理：gzip、compress、deflate、identity）、SSL加速。

Http应用优化和加速说明-负载均衡
浅谈 C/S 和 B/S 架构

HTTP报文信息

报文结构

报文首部+（CR+CF）+报文主体
请求报文
请求行 首部字段 其他（如cookie等）
响应报文
状态行 首部字段 其他（如cookie等）

GET vs POST

GET - 请求来自指定资源的数据
POST - 将要处理的数据提交给指定的资源

常用的HTTP方法

GET： 用于请求访问已经被URI（统一资源标识符）识别的资源，可以通过URL传参给服务器。
POST：用于传输信息给服务器，主要功能与GET方法类似，但一般推荐使用POST方式。
PUT： 传输文件，报文主体中包含文件内容，保存到对应URI位置。
HEAD： 获得报文首部，与GET方法类似，只是不返回报文主体，一般用于验证URI是否有效。
DELETE：删除文件，与PUT方法相反，删除对应URI位置的文件。
MOVE：请求服务器将指定页面移至另一台服务器。
OPTIONS：查询相应URI支持的HTTP方法。

HTTP状态码

1xx：指示信息--表示请求已接收，继续处理
2xx：成功--表示请求已被成功接收、理解、接受
    200：请求被正常处理
    204：请求被受理但没有资源可以返回
    206：客户端只是请求资源的一部分，服务器只对请求的部分资源执行GET方法，相应报文中通过Content-Range指定范围的资源。
3xx：重定向--要完成请求必须进行更进一步的操作
    301：永久性重定向
    302：临时重定向
    303：与302状态码有相似功能，只是它希望客户端在请求一个URI的时候，能通过GET方法重定向到另一个URI上
    304：发送附带条件的请求时，条件不满足时返回，与重定向无关
    307：临时重定向，与302类似，只是强制要求使用POST方法
4xx：客户端错误--请求有语法错误或请求无法实现
    400：请求报文语法有误，服务器无法识别
    401：请求需要认证
    403：请求的对应资源禁止被访问
    404：服务器无法找到对应资源
5xx：服务器端错误--服务器未能实现合法的请求
    500：服务器内部错误
    502：错误网关，作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。，
    503：临时的服务器维护或者过载，服务器当前无法处理请求

HTTP首部

a、通用首部字段（请求报文与响应报文都会使用的首部字段）
Date：创建报文时间
Connection：连接的管理
Cache-Control：缓存的控制
Transfer-Encoding：报文主体的传输编码方式

b、请求首部字段（请求报文会使用的首部字段）
Host：请求资源所在服务器
Accept：可处理的媒体类型
Accept-Charset：可接收的字符集
Accept-Encoding：可接受的内容编码
Accept-Language：可接受的自然语言

c、响应首部字段（响应报文会使用的首部字段）
Accept-Ranges：可接受的字节范围
Location：令客户端重新定向到的URI
Server：HTTP服务器的安装信息

d、实体首部字段（请求报文与响应报文的的实体部分使用的首部字段）
Allow：资源可支持的HTTP方法
Content-Type：实体主类的类型
Content-Encoding：实体主体适用的编码方式
Content-Language：实体主体的自然语言
Content-Length：实体主体的的字节数
Content-Range：实体主体的位置范围，一般用于发出部分请求时使用

HTTPS

HTTP缺点
1 通信使用明文（不加密）可能被窃听
2 不验证通信方身份 有可能遭遇伪装
3 无法证明报文完整性 有可能已遭篡改

HTTPS=HTTP+加密处理（一般是SSL安全通信线路）+认证+完整性保护
1 HTTPS协议需要申请到ca证书，一般免费证书较少，因而需要一定费用。
2 HTTP是超文本传输协议，信息是明文传输，HTTPS则是具有安全性的ssl加密传输协议。
3 HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4 HTTP的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比HTTP协议安全
HTTPS通信过程：

HTTPS通信活动
-> 客户端向服务端发送请求
-> 服务端返回数字证书（hash（服务器身份和公钥）-->信息摘要-->CA私钥加密信息摘要-->数字签名；数字签名+原始信息=数字证书）
-> 客户端用自己的CA[主流的CA机构证书一般都内置在各个主流浏览器中]公钥去解密证书，验证信息摘要，如果证书有问题会提示风险
-> 如果证书没问题客户端会生成一个对称加密的随机秘钥然后再和刚刚解密的服务器端的公钥对数据进行加密,然后发送给服务器端
-> 服务器端收到以后会用自己的私钥对客户端发来的对称秘钥进行解密
-> 之后双方就拿着这个对称加密秘钥来进行正常的通信

HTTP局限
SSL 慢：处理通信量增加，通信慢；处理速度慢，SSL必须进行加密处理，消耗了大量的CPU及内存资源，负载增强
SSL解决方案：使用SSL加速器（专用服务器）

SSL/TSL加密

SSL (Secure Socket Layer)
SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。
SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。
使用：
　　1）认证用户和服务器，确保数据发送到正确的客户机和服务器；
　　2）加密数据以防止数据中途被窃取；
　　3）维护数据的完整性，确保数据在传输过程中不被改变。

TLS 协议
TLS(Transport Layer Security Protocol)：
安全传输层协议 ：TLS记录协议是一种分层协议。每一层中的信息可能包含长度、描述和内容等字段。记录协议支持信息传输、将数据分段到可处理块、压缩数据、应用MAC 、加密以及传输结果等。对接收到的数据进行解密、校验、解压缩、重组等，然后将它们传送到高层客户机。TLS连接状态指的是TLS记录协议的操作环境。它规定了压缩算法、加密算法和MAC算法。TLS记录层从高层接收任意大小无空块的连续数据。密钥计算：记录协议通过算法从握手协议提供的安全参数中产生密钥、 IV 和MAC密钥。
TLS 握手协议由三个子协议组构成，允许对等双方在记录层的安全参数上达成一致、自我认证、例示协商安全参数、互相报告出错条件。

TLS&SSL
TLS的主要目标是使SSL更安全，并使协议的规范更精确和完善。TLS 在SSL v3.0 的基础上，提供了以下增强内容：
1）更安全的MAC算法
2）更严密的警报
3）“灰色区域”规范的更明确的定义
TLS对于安全性的改进
1）对于消息认证使用密钥散列法：TLS 使用“消息认证代码的密钥散列法”（HMAC），当记录在开放的网络（如因特网）上传送时，该代码确保记录不会被变更。SSLv3.0还提供键控消息认证，但HMAC比SSLv3.0使用的（消息认证代码）MAC 功能更安全。
2）增强的伪随机功能（PRF）：PRF生成密钥数据。在TLS中，HMAC定义PRF。PRF使用两种散列算法保证其安全性。如果任一算法暴露了，只要第二种算法未暴露，则数据仍然是安全的。
3）改进的已完成消息验证：TLS和SSLv3.0都对两个端点提供已完成的消息，该消息认证交换的消息没有被变更。然而，TLS将此已完成消息基于PRF和HMAC值之上，这也比SSLv3.0更安全。
4）一致证书处理：与SSLv3.0不同，TLS试图指定必须在TLS之间实现交换的证书类型。
5）特定警报消息：TLS提供更多的特定和附加警报，以指示任一会话端点检测到的问题。TLS还对何时应该发送某些警报进行记录。

Web攻击技术 详见白帽子讲Web安全