http随笔

一、http报文结构和方法

  http请求报文格式：

  

  http应答报文格式：

  以下为http请求、响应报文结构:

  http1.1中请求的方法有：

  GET：获取资源，服务端返回对应资源或CGI（通用网关接口）执行后的输出结果。
  POST：向服务器传输实体的主体，GET也可实现，但一般使用POST。
  HEAD：获得报文首部，类似GET但不返回报文主体部分，可用于获得URI的有效性及资源更新的日期时间等。
  OPTIONS：获得对请求URI指定的资源支持的方法，如GET、POST、HEAD等。
  PUT：向服务器传输文件，类似FTP上传文件一样，一般网站不开放该方法，除非配合WEB应用验证机制或架构设计采用REST标准的网站。
  DELETE：删除文件。
  TRACE：追踪路径，客户端使用该方法发送请求时在Max-Forwards首部字段中填入数值，每经过一个服务器该值会减1，若该值变为0则当前服务器返回状态码200响应。
  CONNECT：请求用隧道协议连接代理，主要使用SSL和TLS将通信内容加密后经网络隧道传输，使用connect方法的格式为：CONNECT 代理服务器名:端口号 HTTP版本，如：

  

二、cookie、session、token

  1、HTTP的无状态  

  在HTTP1.1之前，每次请求-应答数据都要建立-关闭一个连接，服务器认为每次请求都是一个全新的请求，无论该请求是否来自同一地址，因此，HTTP通信是无状态的，当前请求并不会记录它的上一次请求信息。在HTTP1.1中默认允许TCP连接复用（HTTP首部KEEP-Alive字段），以节省建立连接所耗费的时间，但HTTP协议依然保持无状态的特性。因为http是无状态的，那么如何使用http将上下文请求（多次请求）进行关联呢？答案就是使用cookie。cookie分为会话(内存)cookie和持久(硬盘)cookie，比如网站自动登录功能就是利用的持久cookie，而一些网站在关闭后（不关闭浏览器）再次打开依然是登陆状态，这就是利用会话cookie的效果。

  2、cookie

  使用cookie登录相当于是有状态的http，每次请求（甚至关闭浏览器后的再次请求）服务器都可以通过cookie来确认用户是已登录的，相当于服务器在维护着一个seesion。一般的流程是客户首次登录输入用户名密码，服务器登录验证后生成一个sessionID并保存，然后将这个sessionID通过cookie返回给客户端，客户端每次请求都携带保存sessionID的cookie，服务器拿着客户端发来的cookie与保存的seesionID进行验证用户的权限。

  当程序需要为某个客户端的请求创建一个session时，服务器首先检查这个客户端的请求里是否已包含了一个session标识（称为session id），如果已包含则说明以前已经为此客户端创建过session，服务器就按照session id把这个session检索出来使用（检索不到，会新建一个），如果客户端请求不包含session id，则为客户端创建一个session并且生成一个与此session相关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应中返回给客户端保存。保存这个session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发送给服务器。cookie数据存放在客户的浏览器上，session是相对于服务器而言，session数据放在服务器上。

  3、token

  token 的认证方式是无状态的，服务端不保存登陆状态，也就是服务器不保存sessionID来维护与客户端的session。使用token的流程是客户首次登录输入用户名密码，服务器登录验证后签发一个token给客户端（比如说用HMAC-SHA256算法，加上一个他人不知道的密钥，对数据做一个签名，把这个签名和数据一起作为token ，由于密钥别人不知道，所以无法伪造token）。客户端也会将token保存起来，以后发送的每一个请求都携带token，服务器接收请求后拿到 token 去解析认证（比如用同样的HMAC-SHA256 算法和同样的密钥，对数据再计算一次签名， 和客户发来的token 中的签名做个比较，如果不相同就是认证失败）。

  使用token的优势：

  服务器不必保存token来查询，而是直接对客户端发来的token进行验证。
  可以携带其他信息,比如携带具体权限信息之类的，避免了再去查库。
  如果使用了多台服务器的负载均衡，两条请求发给了不同的服务器的话使用cookie就不能达到效果。
  请求中发送token而不再是发送cookie能够防止CSRF(跨站请求伪造)。即使在客户端使用cookie存储token，cookie也仅仅是一个存储机制而不是用于认证。
  请求需要跨域的接口的时候 cookie 就力不从心了，不同域就不会携带 cookie。
  cookie主要是与浏览器交互，对于移动端不太好支持，移动端使用token 就方便得多。

三、http首部和响应状态码

  1、http1.1首部字段

   http首部字段由字段名+字段值构成，中间用分号“:”分隔，如果包含多个字段值的话用逗号“,”分隔，如：“Content-Type: text/html”，"Keep-Alive: timeout=15, max=100"。

  通用首部字段：

  
  请求首部字段：

  
  响应首部字段：

  
  实体首部字段：

  

   如果按照缓存代理和非缓存代理的行为，可以将http首部字段分为端到端（End-to-end）首部和逐跳（Hop-by-hop）首部，逐跳首部只对单次转发有效，会因通过缓存或代理而不再转发。自http/1.1起，如果要使用hop-by-hop首部，需提供Connection首部字段，http/1.1中的逐跳首部字段有以下8个，除这8个首部字段外其它首部字段都属于端到端首部：

    

  关于http首部字段的详细说明参考<<图解http>>。 

  2、http响应状态码

  

1xx ：接收的请求正在处理。
200 OK：请求正常处理。
204 No Content：请求处理成功，且相应无资源返回。
206 Partial Content：请求处理成功，且该请求是范围请求。
301 Moved Permanently：永久性重定向即页面永久性移走，浏览器收到后会自动跳转到一个新的URL地址，且应该将保存的旧地址替换为新地址。
302 Found：页面临时性重定向，浏览器收到后会自动跳转到一个新的URL地址。
303 See Other：类似302功能，但它明确表示客户端应该使用GET方法重定向到指定资源。301、302标准是禁止将POST方法改变成GET方法的，但实际上几乎所有的浏览器都对301、302响应做出把POST改成GET后再次发送请求的做法。
304 Not Modified：资源已找到，但附带条件未满足。附带条件指采用GET方法的请求报文中If-Match、If-None-Match、If-Modified-Since等。
307 Temporary Redirect：类似302功能，但它明确表示客户端不应使用GET方法重定向到指定资源。
400 Bad Request：请求报文中存在语法错误，浏览器会像200 OK一样对待该状态码。
401 Unauthorized：发送的请求需要有http认证（BASIC认证、DIGEST认证）的信息，若之前已进行过一次请求，则表示用户认证失败。浏览器初次接收到401响应会弹出认证用的对话框。
403 Forbidden：访问被拒绝。
404 Not Found：资源未找到。
500 Internal Server Error：服务器执行出错。

502 Bad Gateway 网关错误。
503 Service Unavailable：服务器超负载或停机维护。如果知道服务器恢复的时间最后写入RetryAfter首部字段再返回给客户端。

504 Gateway Timeout网关超时

四、HTTPS

  现代加密方法中一般加密算法是公开的，但解密用的秘钥是保密的。加密和解密使用同一个秘钥的方式为共享秘钥加密，又称对称秘钥加密，对称加密的关键是怎样保证将秘钥安全的发送给对方。公开秘钥加密又称非对称秘钥加密，它使用两把秘钥，一把私有秘钥只有自己知道，一把公开秘钥用来发送给对方。发送方先使用对方的公开秘钥对数据进行加密后再发送给对方，对方根据自己的私有秘钥对数据进行解密，发送的公开秘钥和数据即使被第三方截取到也不能对数据进行解密，因为它没有私有秘钥。

  https是基于网络安全协议SSL/TLS的，SSL使用对称加密 + 非对称加密技术。非对称加密比对称加密处理更复杂，SSL在通信时使用对称加密，而对称加密使用的秘钥在交换的时候则使用非对称加密。

  使用数字签名证书来验证非对称加密中发送的公钥确实是来自服务端的，服务端将公钥使用数字证书认证机构颁发的证书（CA的私钥）来对公钥进行数字签名，客户端使用CA的公钥（一般都内嵌在浏览器中）来对服务端发来的公钥的签名进行验证，验证成功的话即该公钥确实来自服务端而没有被他人替换。浏览器可能没有内置一些非知名CA（数字证书认证机构）的证书或者服务端使用的是通过开源程序OpenSSL构建的一套自己的认证，当浏览器访问该服务时会显示“无法确认连接安全性”或“该网站的安全证书存在问题”等安全提示。

五、HTTP认证

  http认证就是确认用户身份的认证，主要有BASIC认证（基本认证）、DIGEST认证（摘要认证）、SSL客户端认证、FormBase认证（基于表单认证），此外还有Windows统一认证，包括Keberos认证、NTLM认证。

  1、BASIC认证流程：客户端请求资源时服务器会返回带401响应状态码和WWW-Authenticate首部字段的响应，该字段内包含认证方式（BASIC）和认证信息。客户端收到401后在Authorization字段上添加用户ID和密码（一般浏览器会提示用户输入用户名和密码），二者应以冒号连接，并以Base64编码后发送。认证成功后服务器返回状态码200，失败会返回401。

    BASIC认证的缺点是密码明文传输（只是经过了Base64编码）。Base64就是一种基于64个可打印字符来表示二进制数据的方法，具体转换步骤： 

　　第一步，将待转换的字符串每三个字节分为一组，每个字节占8bit，那么共有24个二进制位。
　　第二步，将上面的24个二进制位每6个一组，共分为4组。
　　第三步，在每组前面添加两个0，每组由6个变为8个二进制位，总共32个二进制位，即四个字节。
　　第四步，根据Base64编码对照表（0对应'A'，1对应'B'，...63对应'/'）获得对应的值。

  2、DIGEST认证同BASIC认证一样采用“质询/响应”的方式，但增加了密码加密。其认证流程是：客户端请求资源时服务器会返回带401响应状态码和WWW-Authenticate首部字段的响应，该字段内包含认证方式（DIGEST）和认证信息，且该字段内必须包含realm和nonce这两个字段，客户端会向服务器回送这两个字段值，其中realm通常设为服务器的域名，nonce是一个随机数。客户端收到401后在Authorization字段上添加username、realm、nonce、uri、response（根据用户名、密码等字段值组合后进行MD5运算的值）字段值后发送（一般浏览器会提示用户输入用户名和密码）。服务器收到客户端响应后确认认证的正确性（通过客户端的用户名获得保存的密码，同样与其它字段组合后获得MD5值进行对比），通过的话就返回客户端请求的资源。

    DIGEST认证存在的问题是现在服务器对于用户密码一般都不是明文保存，而是采用MD5值或MD5 + SALT的方式，这样客户端和服务器的密码就不能统一。所谓的MD5 + SALT就是指服务器不是直接计算密码的MD5值，而是再加上另外一个SALT值来计算出MD5值来保存，这个SALT值一般是服务器随机生成的一个长度够长的值，所以只有服务器知道，这样更加安全，避免黑客获得用户密码的散列值后通过查散列值字典（例如MD5密码破解网站），得到某用户的密码。

    DIGEST认证的另一个问题是虽然它能提供防止密码被窃听的保护机制，但不存在防止用户伪装的的保护机制。

  3、SSL客户端认证是指将客户端证书发给客户，并且客户端必须安装此证书，当客户端请求服务器时服务器会发送Certificate Request报文，要求客户端提供客户端证书，用户选择客户端证书后将证书信息以Client Certificate报文方式发送给服务器，服务器验证通过后方可领取证书内客户端的公开秘钥，然后开始HTTPS通信。

    SSL客户端认证可以通过客户端证书来确认当前就是实际用户，但缺点是需要从认证机构购买客户端证书，服务器运营者也可以自己搭建认证机构，但要维持安全运行就会产生相应的费用，一般银行等机构会使用该认证机制。

  4、基于表单认证：基于表单的认证并不是HTTP协议中的标准，一般的流程是客户端将ID和密码等登陆信息以HTTPS通信来发送给服务器，服务器验证客户端的登陆信息后会发放用以识别用户的Session ID，且将用户的认证状态与Session ID绑定后记录在服务端，向客户端返回响应时会在首部字段Set-Cookie内写入Session ID（Session ID应该使用难以揣测的字符串，且服务器也需要进行有效期管理，保证其安全性，另外，为减轻跨站脚本攻击(XSS)造成的损失，建议事先在Cookie内加上httponly属性），客户端收到Session ID后会将其作为Cookie保存在本地，下次向服务器发送请求时，浏览器会自动发送Cookie，所以Session ID也随之发送，这样服务器可以通过接收到的Session ID识别用户和其认证状态。

    现在的web网站多为使用基于表单的认证。

转载于:https://www.cnblogs.com/milanleon/p/9868684.html