全面了解HTTP协议

HTTP协议简介

1.协议：指计算机通信网络中两台计算机之间进行通信所必须共同遵守的规则或规定

2.HTTP协议：超文本传输协议(HTTP)是一种传输协议，它允许将超文本标记语言(HTML)文档从web服务器传送到客户端的浏览器，HTTP协议处于计算机网络中的应用层。

URI和URL的区别

URI (uniform resource identifier) : 统一资源标识符，用来唯一的标识一个资源

URI的组成部分

• 访问资源的命名机制
• 存放资源的主机名
• 资源自身的名称，由路径标识，着重强调于资源

例如：file://a:1234/b/c/d.txt 使用ftp协议表示的资源目标是在a主机下的1234端口的b目录下的c目录的d.txt文件，file是访问资源的命名机制，a:1234是主机名，b/c/d.txt是路径

URL (uniform resource locator) : 统一资源定位器，它是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何locate这个资源

URL的组成部分

• 协议
• 存有该资源的主机IP地址
• 主机资源的具体地址

例如：http://www.baidu.com

HTTP协议的特点

• 简单快速
• 无连接
• 无状态

Http1.1和Http1.0及2.0的区别

HTTP1.1与1.0的区别

• 长连接

  HTTP1.0协议使用非持久连接，即在非持久连接下，一个TCP连接只传输一个Web对象。

  HTTP1.1支持持久连接，也就是说长连接，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。

  一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输，但每个单独的网页文件的请求和应答仍然需要使用各自的连接。HTTP1.1还允许客户端不要等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容，这样就显著的减少了整个下载过程所需要的时间。

  HTTP1.0需要使用keep-alive参数来告知服务器端要建立一个长连接，而HTTP1.1默认支持长连接。HTTP是基于TCP/IP协议的，创建一个TCP连接是需要经过三次握手的，有一定的开销，如果每次通讯都要重新建立连接的话，对性能有影响。因此最好能维持一个长连接。

• 缓存处理

  HTTP/1.0使用头部当中的 If-Modified-Since 参数作为缓存判断的标准，HTTP1.1引入了更多的缓存控制策略，比如Etag / if-None-Match

• 带宽优化

  HTTP/1.0中，存在一些浪费带宽的现象，例如客户端只是请求某个对象的一小部分，而服务器却将整个对象传送过来。例如，客户端只需要显示一个文档的部分内容，又比如下载大文件需要支持断点续传，而不是发送断开连接后不得不重新下载完整的包。

  HTTP1.1中在请求消息中引入了range头域，他允许我们只请求资源的某个部分。在响应消息中Content-Range头域声明了返回的这部分对象的偏移值和长度。如果服务器响应的返回了对象所请求范围的内容，则响应码为206，它可以防止Cache将响应误以为是一个完整的对象。

  节省带宽资源的一个非常有效的做法就是压缩要传送的数据。

• Host头处理

  HTTP/1.0中，我们认为每台服务器绑定唯一的IP地址，因此请求消息中的URL并没有重定向。但是这两年，随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机共享一个IP地址。HTTP1.1在这方面做了改进，它的请求消息和响应消息都支持Host头，并且在请求消息中如果没有Host域，就会报告一个400错误。

HTTP1.1与HTTP1.0存在的问题

• HTTP1.0在传输数据时每次都需要建立长连接，无疑增加了大量的延迟时间。HTTP1.1长连接解决了这个问题
• HTTP1.x在传输数据时，所有传输的内容都是明文，客户端和服务端都无法验证对方的身份，在一定程度上无法保证数据的安全性。可以通过HTTPS来保证数据安全
• HTTP1.x在使用时，header里携带的内容过大，在一定程度上增加了传输的成本。
• 虽然HTTP1.1支持了keep-alive,来弥补多次创建连接产生的延迟，但是keep-alive使用多了同样会给服务端带来大量的性能压力

HTTP1.1与HTTP2.0的区别

• 多路复用

  HTTP2.0使用了多路复用的技术，做到同一个连接并发处理多个请求，而且并发请求的数量比HTTP1.1大了好几个数量级。

  当然HTTP1.1也可以多建立几个TCP连接，来支持处理更多并发的请求，但是创建TCP连接本身也是有开销的。

  TCP连接有一个预热和保护的过程，先检查数据是否传送成功，一旦成功过后，则会慢慢增加传输速度，因此对应瞬时并发的链接，服务器的响应就会变慢。所以最好能使用一个建立好的连接，并且这个连接支持瞬时并发的请求。

• 数据压缩

  我们知道，HTTP请求和响应都是由状态行、请求/响应头部，消息主体三部分组成的。一般而言，消息主体都会经过gzip压缩，或者本身传输的就是压缩过后的二进制文件（如图片、音频等），但是状态行和头部多是没有经过任何压缩，而是以纯文本的方式进行传输的。

  然而，随着web功能越来越多，请求数量越来越多，随之而来的就是头部的流量越来越多，并且在建立初次连接之后的链接也要发送User-Agent等信息，实在是一种浪费，因此，HTTP2.0提出了对请求和响应的头部进行压缩，而不只是压缩主体部分，这种压缩方式就是HAPCK。

• 服务器推送

  为了改善延迟，HTTP2.0引入了Server Push，它允许服务端推送资源给浏览器，在浏览器明确的请求之前，一个服务器经常知道一个页面需要很多附加资源，在它响应浏览器第一个请求的时候，就可以开始推送这些资源。这允许服务端充分的利用一个可能空闲的网络，改善页面加载时间。

Http的request和response的协议组成

请求消息包括请求行（request line）、请求头部（header）、空行和请求数据四个部分组成

请求行由请求方法、URL字段和HTTP协议的版本组成，格式如下：Method Request-URI HTTP-Version CRLF

其中 Method表示请求方法；Request-URI是一个统一资源标识符；HTTP-Version表示请求的HTTP协议版本；CRLF表示回车和换行（除了作为结尾的CRLF外，不允许出现单独的CR或LF字符）。

HTTP请求方法有8种，分别是GET、POST、HEAD、PUT、DELETE、TRACE、CONNECT、OPTIONS。对于移动开发最常用的就是GET和POST了。

请求数据不在GET方法中使用，而在POST方法中使用。POST方法适用于需要客户填写表单的场合，与请求数据相关的最常用的请求报头是Content-Type和Content-Length。

HTTP 的响应报文由状态行、响应报头、空行、响应正文组成。

状态行格式如下所示：HTTP-Version Status-Code Reason-Phrase CRLF

其中，HTTP-Version表示服务器HTTP协议的版本；Status-Code表示服务器发回的响应状态码；Reason-
Phrase表示状态码的文本描述。状态码由3位数字组成，第一个数字定义了响应的类别，且有以下5种可能取值。
• 100～199：指示信息，收到请求，需要请求者继续执行操作。
• 200～299：请求成功，请求已被成功接收并处理。
• 300～399：重定向，要完成请求必须进行更进一步的操作。
• 400～499：客户端错误，请求有语法错误或请求无法实现。
• 500～599：服务器错误，服务器不能实现合法的请求。
常见的状态码如下:
• 200 OK：客户端请求成功。
• 400 Bad Request：客户端请求有语法错误，服务器无法理解。
• 401 Unauthorized：请求未经授权，这个状态码必须和WWW-Authenticate报头域一起使用。
• 403 Forbidden：服务器收到请求，但是拒绝提供服务。
• 500 Internal Server Error：服务器内部错误，无法完成请求。
• 503 Server Unavailable：服务器当前不能处理客户端的请求，一段时间后可能恢复正常。

消息报头

消息报头分为通用报头、请求报头、响应报头、实体报头等。消息报头由键值对组成，每行一对，关
键字和值用英文冒号“：”分隔。

1.通用报头：它既可以出现在请求报头，也可以出现在响应报头中，如下所示
• Date：表示消息产生的日期和时间。
• Connection：允许发送指定连接的选项。例如指定连接是连续的；或者指定“close”选项，通知服务
器，在响应完成后，关闭连接。
• Cache-Control：用于指定缓存指令，缓存指令是单向的（响应中出现的缓存指令在请求中未必会出
现），且是独立的（一个消息的缓存指令不会影响另一个消息处理的缓存机制）。

2.请求报头：通知服务器关于客户端请求的信息。典型的请求报头如下所示
• Host：请求的主机名，允许多个域名同处一个IP地址，即虚拟主机。
• User-Agent：发送请求的浏览器类型、操作系统等信息。
• Accept：客户端可识别的内容类型列表，用于指定客户端接收哪些类型的信息。
• Accept-Encoding：客户端可识别的数据编码。
• Accept-Language：表示浏览器所支持的语言类型。
• Connection：允许客户端和服务器指定与请求/响应连接有关的选项。例如，这时为Keep-Alive则表示
保持连接。
• Transfer-Encoding：告知接收端为了保证报文的可靠传输，对报文采用了什么编码方式。

3.响应报头：用于服务器传递自身信息的响应。常见的响应报头如下所示 • Location：用于重定向接收者到一个新的位置，常用在更换域名的时候。
• Server：包含服务器用来处理请求的系统信息，与User-Agent请求报头是相对应的。

4.实体报头：用来定义被传送资源的信息，其既可用于请求也可用于响应。请求和响应消息都可以传送一
个实体。常见的实体报头如下所示
• Content-Type：发送给接收者的实体正文的媒体类型。
• Content-Lenght：实体正文的长度。
• Content-Language：描述资源所用的自然语言。
• Content-Encoding：实体报头被用作媒体类型的修饰符。它的值指示了已经被应用到实体正文的附加内容的编码，因而要获得Content-Type报头域中所引用的媒体类型，必须采用相应的解码机制。
• Last-Modified：实体报头用于指示资源的最后修改日期和时间。
• Expires：实体报头给出响应过期的日期和时间。

get/post方法的区别

get是获取资源，post是提供更新服务器上的资源

• 提交的数据

  get提交的数据一般放在URL之后用?分割，post提交数据基本都是放在body中

• 提交的数据大小是否有限制

  get提交数据大小有限制，因为浏览器对URL是有限制的，不可能无限制的输入一个URL地址。post提交数据，由于提交的是body，所以大小是没有限制的

• 取得变量的值

get是通过Request.QueryString方式来获得变量值，post是通过Request.Form来获取变量值

• 安全问题

  get提交数据会带来安全问题，比如提交账户密码都会显示在URL上

Cookie和Session

• Cookie技术是客户端的解决方案，Cookie就是由服务器发给客户端的特殊信息，而这些信息以文本文件的方式存放在客户端，然后客户端每次向服务器发送请求的时候都会带上这些特殊的信息。Cookie是客户端保存用户信息的一种机制，用来记录用户的一些信息，也是实现Session的一种方式。

  Cookie是由服务器端生成，发送给User-Agent（一般是web浏览器），浏览器会将Cookie的key/value保存到某个目录下的文本文件内，下次请求同一网站时就发送该Cookie给服务器（前提是浏览器设置为启用Cookie）。Cookie名称和值可以由服务器端开发自己定义，对于JSP而言也可以直接写入Sessionid，这样服务器可以知道该用户是否合法用户以及是否需要重新登录等。

• Session是另一种记录客户状态的机制，不同的是Cookie保存在客户端浏览器中，而Session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。

  由于HTTP协议是无状态的协议，所以服务端需要记录用户的状态时，就需要用某种机制来识别具体的用户，这个机制就是Session.典型的场景比如购物车，当你点击下单按钮时，由于HTTP协议无状态，所以并不知道是哪个用户操作的，所以服务端要为特定的用户创建了特定的Session，用于标识这个用户，并且跟踪用户，这样才知道购物车里面有几本书。创建了特定的Session的同时，服务器会为该Session生成唯一的Session Id。Session被创建之后，就可以调用Session相关的方法往Session中增加内容。这个Session是保存在服务端的，有一个唯一标识。在服务端保存Session的方法很多，内存、数据库、文件都有。集群的时候也要考虑Session的转移，在大型的网站，一般会有专门的Session服务器集群，用来保存用户会话，这个时候 Session 信息都是放在内存的。

  具体到Web中的Session指的就是用户在浏览某个网站时，从进入网站到浏览器关闭所经过的这段时间，也就是用户浏览这个网站所花费的时间。因此从上述的定义中我们可以看到，Session实际上是一个特定的时间概念。

  当客户端访问服务器时，服务器根据需求设置Session，将会话信息保存在服务器上，同时将标示Session的SessionId传递给客户端浏览器，浏览器将这个SessionId保存在内存中，我们称之为无过期时间的Cookie。浏览器关闭后，这个Cookie就会被清掉，它不会存在于用户的Cookie临时文件。以后浏览器再次发送请求都会额外加上这个Session Id，服务器会根据这个Session Id找到相应的Session，就能取得客户端的数据信息。

  如果客户端浏览器意外关闭，服务器保存的Session数据不是立即释放，此时数据还会存在，只要我们知道那个SessionId,就可以继续通过请求获得此Session的信息，因为此时后台的Session还存在，当然我们可以设置一个Session超时时间，一旦超过规定时间没有客户端请求时，服务器就会清除对应SessionId的Session信息。

• 总结一下Cookie和Session的区别

  存放位置不同：Cookie存放在客户端，Session存放在服务器

  存取方式不同：Cookie保存的是字符串，Session中能够存取任何类型的数据

  安全性（隐私策略）的不同：Cookie对客户端是可见的，客户端一些程序有可能去修改Cookie。Session存储在服务端，对客户端不可见，不存在敏感信息泄露风险。

  有效期不同：一般Cookie有效期会设置很长时间，而Session依赖于当中的一个id，如果把id设为-1，那么关闭了浏览器Session就会失效。

  对服务器造成的压力不同：Session保存在服务端，每个用户都会产生一个Session，当多个用户并发访问的时候就会产生很多Session，会非常消耗内存。Cookie保存在客户端，不占用服务端资源。所以多用户并发的时候，Cookie是一个比较好的选择。

HTTPS

HTTPS并不是一个单独的协议，而是在加密连接(SSL/TLS)上的常规HTTP协议。通过在TCP和HTTP之间加入TLS (Transport Layer Security) 来加密。SSL协议，是一种安全传输协议，TLS 是 SSL V3.0升级版

• HTTPS传输速度

  通信慢（相比HTTP还要处理TLS通信）

  SSL必须进行加密处理（客户端和服务器都要进行加解密，需要消耗更多资源）

Https加密原理

加密算法的类型基本上分为了两种：

• 对称加密，加密用的密钥和解密用的密钥是同一个，比较有代表性的就是 DES、AES 加密算法。对称加密的优点是计算速度快，缺点是密钥需要在通讯的两端共享。
• 非对称加密，加密用的密钥称为公钥，解密用的密钥称为私钥。服务端生成配对的公钥和私钥，私钥保存在客户端，公钥发送给客户端，客户端使用公钥加密明文传输给服务端，服务端使用私钥解密。经常使用到的 RSA 加密算法就是非对称加密的。

相比较对称加密而言，非对称加密安全性更高，但是加解密耗费的时间更长，速度慢。HTTPS = HTTP + SSL，HTTPS 的加密就是在 SSL 中完成的。HTTPS采用的是对称加密和非对称加密的结合的方式保证安全，为了保证密钥的安全，还引入了数字签名和数字证书。

数字签名：用于验证传输的内容是不是真实服务器发送的数据，发送的数据有没有被篡改过，是非对称加密的一种应用场景。不过它是反过来用私钥来加密，通过与之配对的公钥来解密。

数字签名的过程：

1.服务端把报文经过Hash处理后生成摘要信息Digest，摘要信息使用私钥加密之后就生成签名，服务器把签名连同报文一起发送给客户端。

2.客户端接收到数据后，把签名提取出来用公钥解密，如果能正常解密出来Digest2，那么就能确认是对方发的。

3.客户端把报文Text提取出来做同样的Hash处理，得到的摘要信息Digest1，再与之前解密出来的Digest2对比，如果两者相同表明内容没有被篡改过。

数字证书：简称CA，它由权威机构给某网站颁发的一种认可凭证，这个凭证是被大家(浏览器)所认可的。数字证书主要是保证你使用的公钥是真实服务器发送给你的。

https://juejin.im/post/5b48b0d7e51d4519962ea383#heading-23

HTTPS加密原理详解可以看这：https://blog.csdn.net/guolin_blog/article/details/104546558

网络分层

1.物理层
该层负责比特流在节点间的传输，即负责物理传输。该层的协议既与链路有关，也与传输介质有关。
其通俗来讲就是把计算机连接起来的物理手段。
2.数据链路层
该层控制网络层与物理层之间的通信，其主要功能是如何在不可靠的物理线路上进行数据的可靠传递。为了保证传输，从网络层接收到的数据被分割成特定的可被物理层传输的帧。帧是用来移动数据的结构包，它不仅包括原始数据，还包括发送方和接收方的物理地址以及纠错和控制信息。其中的地址确定了帧将发送到何处，而纠错和控制信息则确保帧无差错到达。如果在传送数据时，接收点检测到所传数据中有差错，就要通知发送方重发这一帧。
3.网络层
该层决定如何将数据从发送方路由到接收方。网络层通过综合考虑发送优先权、网络拥塞程度、服务
质量以及可选路由的花费来决定从一个网络中的节点 A 到另一个网络中节点 B 的最佳路径。
4.传输层
该层为两台主机上的应用程序提供端到端的通信。相比之下，网络层的功能是建立主机到主机的通信。传输层有两个传输协议：TCP（传输控制协议）和UDP（用户数据报协议）。其中，TCP是一个可靠的面向连接的协议，UDP是不可靠的或者说无连接的协议。
5.应用层
应用程序收到传输层的数据后，接下来就要进行解读。解读必须事先规定好格式，而应用层就是规定
应用程序的数据格式的。它的主要协议有HTTP、FTP、Telnet、SMTP、POP3等。

TCP三次握手四次挥手

相关报文段说明

ACK ： TCP协议规定，只有ACK=1时有效，也规定连接建立后所有发送的报文的ACK必须为1

SYN(SYNchronization) ： 在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这是一个连接请求报文。对方若同意建立连接，则应在响应报文中使SYN=1和ACK=1. 因此, SYN置1就表示这是一个连接请求或连接接受报文。

FIN （finish）即完，终结的意思， 用来释放一个连接。当 FIN = 1 时，表明此报文段的发送方的数据已经发送完毕，并要求释放连接。

TCP三次握手的过程如下。

第一次握手：建立连接。客户端发送连接请求报文段，将 SYN 设置为 1、Sequence Number（seq）为
x；接下来客户端进入SYN_SENT状态，等待服务端的确认。
第二次握手：服务器收到客户端的 SYN 报文段，对 SYN 报文段进行确认，设置Acknowledgment
Number（ACK）为 x+1（seq+1）；同时自己还要发送 SYN 请求信息，将SYN设置为1、seq为y。服务端将上述所有信息放到SYN+ACK报文段中，一并发送给客户端，此时服务端进入SYN_RCVD状态。
第三次握手：客户端收到服务端的SYN+ACK报文段；然后将ACK设置为y+1，向服务端发送ACK报文段，这个报文段发送完毕后，客户端和服务端都进入ESTABLISHED （TCP连接成功）状态，完成TCP的
三次握手。
当客户端和服务端通过三次握手建立了TCP连接以后，当数据传送完毕，断开连接时就需要进行TCP的
四次挥手。

四次挥手的过程

第一次挥手：客户端设置seq和ACK，向服务端发送一个FIN报文段。此时，客户端进入FIN_WAIT_1
状态，表示客户端没有数据要发送给服务端了。
第二次挥手：服务端收到了客户端发送的FIN报文段，向客户端回了一个ACK报文段。
第三次挥手：服务端向客户端发送 FIN 报文段，请求关闭连接，同时服务端进入LAST_ACK状态。
第四次挥手：客户端收到服务端发送的FIN报文段，向服务端发送ACK报文段，然后客户端进入TIME_WAIT状态。服务端收到客户端的ACK报文段以后，就关闭连接。此时，客户端等待2MSL（最大报
文段生存时间）后依然没有收到回复，则说明服务端已正常关闭，这样客户端也可以关闭连接了。

TCP和UDP的区别

1、基于连接与无连接

2、对系统资源的要求（TCP较多，UDP少）

3、UDP程序结构较简单

4、流模式与数据报模式

5、TCP保证数据正确性，UDP可能丢包

6、TCP保证数据顺序，UDP不保证

如何设计在 UDP 上层保证 UDP 的可靠性传输

传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照TCP可靠性传输的方式。如不考虑拥塞处理，可靠UDP的简单设计如下：

• 1、添加seq/ack机制，确保数据发送到对端
• 2、添加发送和接收缓冲区，主要是用户超时重传。
• 3、添加超时重传机制。

具体过程即是：送端发送数据时，生成一个随机seq=x，然后每一片按照数据大小分配seq。数据到达接收端后接收端放入缓存，并发送一个ack=x的包，表示对方已经收到了数据。发送端收到了ack包后，删除缓冲区对应的数据。时间到后，定时任务检查是否需要重传数据。

目前有如下开源程序利用udp实现了可靠的数据传输。分别为RUDP、RTP、UDT

1、RUDP（Reliable User Datagram Protocol）

RUDP 提供一组数据服务质量增强机制，如拥塞控制的改进、重发机制及淡化服务器算法等。

2、RTP（Real Time Protocol）

RTP为数据提供了具有实时特征的端对端传送服务，如在组播或单播网络服务下的交互式视频音频或模拟数据。

3、UDT（UDP-based Data Transfer Protocol）

UDT的主要目的是支持高速广域网上的海量数据传输。

关于RUDP、RTP、UDT的更多介绍请查看此处