HTTP基本知识

一、相关文档链接

几个代表性状态码：https://blog.csdn.net/qq_34600232/article/details/87599230

全讲解：https://zhuanlan.zhihu.com/p/72616216

URI：https://baike.baidu.com/item/URI/2901761?fr=aladdin

get和post区别：https://blog.csdn.net/ever_siyan/article/details/87935455

HTTP和HTTPS的全解析：https://blog.csdn.net/xiaoming100001/article/details/81109617

二、学习笔记

1. 代表性的状态码
    

   1. 1XX的响应结果表示收到信息，需要请求者继续操作。
       

   2. 2XX 的响应结果表明请求被正常处理了。

      200 OK：表示从客户端发来的请求在服务器端被正常处理了。

      204 No Content：

      该状态码代表服务器接收的请求已成功处理，但在返回的响应报文中不含实体的主体部分。另外，也不允许返回任何实体的主体。比如，当从浏览器发出请求处理后，返回 204 响应，那么浏览器显示的页面不发生更新。一般在只需要从客户端往服务器发送信息，而对客

      户端不需要发送新消息的内容的情况下使用。 

      206 Partial Content : 表示客户端进行了范围请求，而服务器成功的执行了这部分GET请求，响应报文中包含Content-Page指定范围的实体内容。

   3. 3XX 响应结果表明浏览器需要执行某些特殊的处理以正确处理请求。

      301 Moved Permanently：永久性重定向。该状态码表示请求的资源已被分配了新的 URI，以后应使用资源现在所指的 URI。也就是说，如果已经把资源对应的 URI保存为书签了，这时应该按 Location 首部字段提示的 URI 重新保存。

      302 Found ：临时重定向。该状态码表示请求的资源已被分配了新的 URI，希望用户（本次）能使用新的 URI 访问。

      303 See Other：该状态码表示由于请求对应的资源存在着另一个 URI，应使用 GET方法定向获取请求的资源。

      304 Not Modified ：该状态码表示客户端发送附带条件的请求 2 时，服务器端允许请求访问资源，但未满足条件的情况。304 状态码返回时，不包含任何响应的主体部分。304 虽然被划分在 3XX 类别中，但是和重定向没有关系。

      307 Temporary Redirect：临时重定向。
       

   4. 4XX 的响应结果表明客户端是发生错误的原因所在。

      400 Bad Request：该状态码表示请求报文中存在语法错误。当错误发生时，需修改请求的内容后再次发送请求。另外，浏览器会像 200 OK 一样对待该状态码。

      401 Unauthorized：

      该状态码表示发送的请求需要有通过 HTTP 认证（BASIC 认证、DIGEST 认证）的认证信息。另外若之前已进行过 1 次请求，则表示用户认证失败。
      403 Forbidden：该状态码表明对请求资源的访问被服务器拒绝了。服务器端没有必要给出拒绝的详细理由，但如果想作说明的话，可以在实体的主体部分对原因进行描述，这样就能让用户看到了。未获得文件系统的访问授权，访问权限出现某些问题（从未授权的发送源 IP 地址试图访问）等列举的情况都可能是发生 403 的原因。

      404 Not Found：该状态码表明服务器上无法找到请求的资源。除此之外，也可以在服务器端拒绝请求且不想说明理由时使用。
       

   5. 5XX 的响应结果表明服务器本身发生错误。

      500 Internal Server Error：该状态码表明服务器端在执行请求时发生了错误。也有可能是 Web应用存在的 bug 或某些临时的故障。

      503 Service Unavailable：该状态码表明服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。如果事先得知解除以上状况需要的时间，最好写入RetryAfter 首部字段再返回给客户端。
       

2. URI和URL的区别（https://baike.baidu.com/item/URI/2901761?fr=aladdin）

   HTTP使用统一资源标识符（Uniform Resource Identifiers, URI）来传输数据和建立连接。

   • URI：Uniform Resource Identifier 统一资源标识符
   • URL：Uniform Resource Location 统一资源定位符

   URI 是用来标示 一个具体的资源的，我们可以通过 URI 知道一个资源是什么。目前可以包含URL的全部信息（但是URL只是一部分的URI），可是由于URL不确定性（即信息存放地址发生改变时，URL必须做出相应的改变），我们希望能够研究出一种不随地址改变而改变的URI标识符（或者是URN）。

   URL 则是用来定位具体的资源的，标示了一个具体的资源位置。互联网上的每个文件都有一个唯一的URL。

3. 常见的请求方法

   1. GET:请求指定的页面信息，并返回实体主体。
   2. POST:向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
   3. HEAD:类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头
   4. PUT:从客户端向服务器传送的数据取代指定的文档的内容。
   5. DELETE:请求服务器删除指定的页面。
       
4. HTTP和HTTPS
   1. HTTP传输的缺点
      • 请求信息明文传输，容易被窃听截取。
      • 数据的完整性未校验，容易被篡改
      • 没有验证对方身份，存在冒充危险

   2. 为了解决上述HTTP存在的问题，就用到了HTTPS。
      HTTPS 协议（HyperText Transfer Protocol over Secure Socket Layer）：一般理解为HTTP+SSL/TLS，通过 SSL证书来验证服务器的身份，并为浏览器和服务器之间的通信进行加密。（其实并不是真正的完全加密，还是存在破解隐患）

   3. 什么是SSL

      SSL（Secure Socket Layer，安全套接字层）：1994年为 Netscape 所研发，SSL 协议位于 TCP/IP 协议与各种应用层协议之间，为数据通讯提供安全支持。

      TLS（Transport Layer Security，传输层安全）：其前身是 SSL，它最初的几个版本（SSL 1.0、SSL 2.0、SSL 3.0）由网景公司开发，1999年从 3.1 开始被 IETF 标准化并改名，发展至今已经有 TLS 1.0、TLS 1.1、TLS 1.2 三个版本。SSL3.0和TLS1.0由于存在安全漏洞，已经很少被使用到。TLS 1.3 改动会比较大，目前还在草案阶段，目前使用最广泛的是TLS 1.1、TLS 1.2。

   4. HTTPS的传输过程
      
      1. 首先客户端通过URL访问服务器建立SSL连接。
      2. 服务端收到客户端请求后，会将网站支持的证书信息（证书中包含公钥）传送一份给客户端。
      3. 客户端的服务器开始协商SSL连接的安全等级，也就是信息加密的等级。
      4. 客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。
      5. 服务器利用自己的私钥解密出会话密钥。
      6. 服务器利用会话密钥加密与客户端之间的通信。
   5. HTTPS的缺点
      • HTTPS协议多次握手，导致页面的加载时间延长近50%；
      • HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗；
      • 申请SSL证书需要钱，功能越强大的证书费用越高。
      • SSL涉及到的安全算法会消耗 CPU 资源，对服务器资源消耗较大。
   6. 总结HTTP和HTTPS的区别
      • HTTPS是HTTP协议的安全版本，HTTP协议的数据传输是明文的，是不安全的，HTTPS使用了SSL/TLS协议进行了加密处理。
      • http和https使用连接方式不同，默认端口也不一样，http是80，https是443。
5. HTTP全链路解析过程
   
   
    
6. 长连接、短连接
   1. 优缺点

      由上可以看出，长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间。对于频繁请求资源的客户来说，较适用长连接。不过这里存在一个问题，存活功能的探测周期太长，还有就是它只是探测TCP连接的存活，属于比较斯文的做法，遇到恶意的连接时，保活功能就不够使了。在长连接的应用场景下，client端一般不会主动关闭它们之间的连接，Client与server之间的连接如果一直不关闭的话，会存在一个问题，随着客户端连接越来越多，server早晚有扛不住的时候，这时候server端需要采取一些策略，如关闭一些长时间没有读写事件发生的连接，这样可 以避免一些恶意连接导致server端服务受损；如果条件再允许就可以以客户端机器为颗粒度，限制每个客户端的最大长连接数，这样可以完全避免某个蛋疼的客户端连累后端服务。

      短连接对于服务器来说管理较为简单，存在的连接都是有用的连接，不需要额外的控制手段。但如果客户请求频繁，将在TCP的建立和关闭操作上浪费时间和带宽。

      长连接和短连接的产生在于client和server采取的关闭策略，具体的应用场景采用具体的策略，没有十全十美的选择，只有合适的选择。

   2. 长短链接使用时机的选择
      长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况，。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。 
        
      而像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连好。

三、思考

1. get和post区别(https://blog.csdn.net/ever_siyan/article/details/87935455)
   1. get是不安全的，pots是安全的。在url请求中，get数据直接放在url中，而post的所有操作对用户是不可见的
   2. get受url长度限制导致传送的数据量较小。post传送的数据量较大，一般默认为不受限制
   3. get限制了form表单必须为ASCII字符集。post支持整个ISO10646字符集（此iso标准和unicode用的是用一套字符编码，内容也全部一样，可以理解为同一个东西，就是制定标准的组织不同）
   4. get的执行效率更高，且get是form提交的默认方法
   5. get成功返回一次200；post需要返回两次，第一次是100表示可以继续传输，第二次200才表示request body全部传输过去
       
2. 短链接和长连接

   在HTTP/1.0中，默认使用的是短连接。也就是说，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。如果客户端浏览器访问的某个HTML或其他类型的 Web页中包含有其他的Web资源，如JavaScript文件、图像文件、CSS文件等；当浏览器每遇到这样一个Web资源，就会建立一个HTTP会话。

   但从 HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头有加入这行代码：

   Connection:keep-alive

   在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的 TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接要客户端和服务端都支持长连接。

   HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。