计算机网络知识点——应用层HTTP协议

• HTTP

• HTTP的请求报文结构

HTTP请求报文主要由请求行、请求头、空行、请求正文（Get请求没有请求正文）4部分组成。

1. 请求行。由 3 部分组成，分别为：请求方法、URL 以及协议版本，之间由空格分隔。请求方法包括 GET、HEAD、PUT、POST、TRACE、OPTIONS、DELETE 以及扩展方法，当然并不是所有的服务器都实现了所有的方法，部分方法即便支持，出于安全性的考虑也是不可用的。协议版本的格式为：HTTP/主版本号.次版本号，常用的有 HTTP/1.0和HTTP/1.1。
2. 请求头。请求头部为请求报文添加了一些附加信息，由“名/值”对组成，每行一对，名和值之间使用冒号分隔。常见请求头如下：
3. 空行。请求头的最后会有一个空行， 表示请求头部结束，接下来为请求正文，这一行非常重要，必不可少。
4. 请求正文。可选部分，比如 T GET  请求就没有请求正文。

• HTTP的响应报文结构

主要由状态行、响应头、空行、响应正文 4 部分组成。

1. 状态行。由3部分组成，分别为：协议版本，状态码，状态码描述，之间由空格分隔。
2. 响应头。与请求头类似，为响应报文添加了一些附加信息。
3. 空行。
4. 响应正文。

• 常见的HTTP首部字段

1. 通用首部字段（请求报文和响应报文都会使用的首部字段）。
   1. Date：创建报文时间
   2. Connection：连接的管理
   3. Cache-Control：缓存的控制
   4. Transfer-Encoding：报文主体的传输编码方式，如 Transfer-Encoding ：chunked 。
2. 请求首部字段。
   1. Host：请求资源所在服务器
   2. Accept：可处理的媒体类型
   3. Accept-Charset：可接收的字符集
   4. Accept-Encoding：可接受的内容编码
   5. ccept-Language：可接受的自然语言
   6. Referer：HTTP Referer 是 header 的一部分，当浏览器向 web 服务器发送请求的时候，一般会带上 Referer， 告诉服务器我是从哪个页面链接过来的，服务器籍此可以获得一些信息用于处理。比如从我主页上链接到一个朋友那里，他的服务器就能够从 HTTP Referer中统计出每天有多少用户点击我主页上的链接访问他的网站。如果是 CSRF 攻击传来的请求，Referer 字段会是 包含恶意网址的地址，这时候服务器就能识别出恶意的访问。
3. 响应首部字段。
   1. Accept-Ranges：可接受的字节范围
   2. Location：令客户端重新定向到的 URI
   3. Server：HTTP 服务器的安装信息
4. 实体首部字段（请求报文和响应报文的实体部分使用的首部字段）。
   1. Allow：资源可支持的HTTP 方法
   2. Content-Type：实体主类的类型
   3. Content-Encoding：实体主体适用的编码方式
   4. Content-Language：实体主体的自然语言
   5. Content-Length： 实体主体的字节数
   6. Content-Range：实体主体的位置范围，一般用于发出部分请求时使用。

• HTTP状态吗及含义

1、200OK：服务器已成功处理了请求 并提供了请求的网页。

2、202 Accepted：已经接受请求，但处理尚未完成。

3、204 No Content：没有新文档，浏览器应该继续显示原来的文档。

4、206 Partial Content：客户端进行了范围请求。响应报文中由 Content-Range 指定实体内容的范围。实现断点续传。

1、301Moved Permanently：永久性重定向。请求的网页已永久移动到新位置。

2、302（或 307））Moved Temporatily：临时性重定向。请求的网页临时移动到新位置。

3、304 Not Modified：未修改。自从上次请求后，请求的内容未修改过。

 

1、401 Unauthorized：客户试图未经授权访问受密码保护的页面。应答中会包含一个WWW-Authenticate 头，浏览器据此显示用户名字/密码对话框，然后在填写合适的Authorization 头后再次发出请求。

2、403 Forbidden：服务器拒绝请求。

3、404 Not Found： 服务器上不存在客户机所请求的资源。

 

1、500 Internal Server Error（服务器内部错误）：服务器遇到一个错误，使其无法为请求提供服务。

2、501 Not Implemented（未实现）：服务器不支持实现请求所需要的功能。例如，客户端发出了一个服务器不支持的PUT（从客户端想服务器传送的数据取代指定的文档的内容）的请求。

3、502 Bad Gateway（错误网关）：服务器作为网关或代理时，为了完成请求访问下一个服务器，但该服务器返回了非法应答。

4、503 Service Unavailable（服务不可用）：服务器由于未获或者负载过重未能应答。例如，Servlet可能在数据库连接池已满的情况下返回503.当服务器返回503时，可以提供一个Retry-After头。

5、504 Gateway Timeout（网关超时）：由作为代理或网关的服务器使用，表示不能及时地从远程服务器获得应答（HTTP1.1 新）。

6、505 HTTP Version Not Supported（HTTP版本不受支持）：服务器不支持请求中所指名的HTTP版本（HTTP1.1 新）。

• HTTP的浏览器缓存机制与缓存的首部字段

1、Last-Modified 和 If-Modified-Since

简单的说，Last-Modified与If-Modified-Since都是用于记录页面最后修改时间的HTTP 头信息，只是Last-Modified是由服务器往客户端发送的HTTP头，而If-Modified-Since则是由客户端往服务器发送的头，可以看到，再次请求本地存在的缓存页面时，客户端会通过 If-Modified-Since 头把浏览器端缓存页面的最后一次被服务器修改的时间一起发到服务器去，服务器会把这个时间与服务器上实际文件的最后修改时间进行比较，通过这个时间戳判断客户端的页面是否是最新的，如果不是最新的，就返回 HTTP状态码 200 和新的文件内容，客户端接到之后，会丢弃旧文件，把新文件缓存起来，并显示到浏览器中；如果是最新的，则返回 304 告诉客户端其本地缓存的页面是最新的，就直接把本地缓存文件显示到浏览器中，这样在网络上传输的数据量就会大大减少，同时也减轻了服务器的负担。

在浏览器第一次请求某一个URL时，服务器端的返回状态会是200，内容是你请求的资源，同时有一个Last-Modified 的属性标记此文件在服务期端最后被修改的时间。格式类似这样：Last-Modified: Fri, 12 May 2006 18:53:33 GMT。

客户端第二次请求此 URL  时，浏览器会向服务器传送 If-Modified-Since 报头，询问该时间之后文件是否有被修改过：If-Modified-Since: Fri, 12 May 2006 18:53:33 GMT。

如果服务器端的资源没有变化，则自动返回 HTTP 304 状态码，内容为空，这样就节省了传输数据量。当服务器端代码发生改变或者重启服务器时，则重新发出资源，返回和第一次请求时类似，从而保证不向客户端重复发出资源，也保证当服务器有变化时，客户端能够得到最新的资源。

1. ETag和If-None-Match

ETag和If-None-Match 是一种常用的判断资源是否改变的方法。类似于 Last-Modified和If-Modified-Since。但是有所不同的是 Last-Modified 和 If-Modified-Since 只判断资源的最后修改时间，而 ETag 和 If-None-Match 可以是资源任何的任何属性，比如资源的 MD5等。

ETag 和 If-None-Match 的工作原理是在 HTTP Response 中添加 ETags 信息。当客户端再次请求该资源时，将在 HTTP Request 中加入 If-None-Match 信息（也就是 ETags 的值）。如果服务器验证资源的 ETags 没有改变（该资源的内容没有改变），将返回一个 304状态；否则，服务器将返回 200 状态，并返回该资源和 新的 ETags。

服务器会为每个资源分配对应的 ETag 值，根据资源的内容得到其值。当资源内容发生改变时，其值也会改变。以下是服务器端返回的格式：

ETag: "50b1c1d4f775c61:df3"

客户端的查询更新格式是这样的：

If-None-Match: W/"50b1c1d4f775c61:df3"

如果 ETag 没改变，则返回状态 304，这也和 Last-Modified 一样。

1. Expires / Cache-Control（优先使用）

用来控制缓存的失效日期，控制浏览器是直接从浏览器缓存取数据还是重新发请求到服务器取数据。

Expires 是 Web 服务器响应消息头字段，在响应 http 请求时告诉浏览器在过期时间前浏览器可以直接从浏览器缓存取数据，而无需再次请求。Expires 的一个缺点就是，返回的到期时间是服务器端的时间，这样存在一个问题，如果客户端的时间与服务器的时间相差很大（比如时钟不同步，或者跨时区），那么误差就很大，所以在 HTTP 1.1 版开始，使用 Cache-Control: max-age=(秒)替代。

Cache-Control，比如：Cache-Control: max-age=315360000。这里声明的是一个相对的 秒数，表示从现在起，315360000 秒内缓存都是有效的，这样就避免了服务端和客户端时间不一致的问题。

但是 Cache-Control 是 HTTP1.1才有的，不适用于HTTP1.0，而Expires 既适用于HTTP1.0，也适用于 HTTP1.1，所以说在大多数情况下同时发送这两个头会是一个更好的选择，当客户端两种头都能解析的时候，会优先使用Cache-Control。

1. 缓存字段执行过程

1. 客户端请求一个页面（A）。
2. 服务器返回页面 A，并在给 A 加上一个 Last-Modified 和 ETag。
3. 客户端展现该页面，并将页面连同 Last-Modified 和 ETag 的值一起缓存。
4.  客户再次请求页面 A，并将上次请求时服务器返回的 Last-Modified 和 ETag 的值一起传递给服务器。
5.  服务器检查该 Last-Modified 或 ETag，并判断出该页面自上次客户端请求之后还未被修改，直接返回响应 304 和一个空的响应体。

• Http1.1和Http1.0的区别（HTTP1.1版本的4个新特性）

1. 默认持久连接和流水线。

HTTP/1.1 默认使用持久连接，只要客户端服务端任意一端没有明确提出断开 TCP 连接，就一直保持连接，在同一个 TCP 连接下，可以发送多次 HTTP 请求。同时，默认采用流水线的方式发送请求，即客户端 每遇到一个对象引用就立即发出一个请求，而不必等到收到前一个响应之后才能发出下一个请求，但服务器端必须按照接收到客户端的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容，这样也显著地减少了整个下载过程所需的时间。

HTTP/1.0 默认使用短连接，要建立长连接，可以在请求消息中包含 Connection:Keep-Alive 头域，如果服务器愿意维持这条连接，在响应消息中也会包含一个 Connection:Keep-Alive 的头域。Connection 请求头的值为 Keep-Alive 时，客户端通知服务器返回本次请求结果后保持连接；Connection 请求头的值为 close 时，客户端通知服务器返回本次请求结果后关闭连接。

1. 分块传输数据。

HTTP/1.0 可用来 指定实体长度的唯一机制是通过 Content-Length 字段。静态资源的长度可以很容易地确定，但是 对于动态生成的响应来说，为获取它的真实长度， 只能等它完全生成之后，才能正确地填写 Content-Length  的值， 这便要求缓存整个响应，在服务器端占用大量的缓存，从而延长了响应用户的时间。

HTTP/1.1 引入了被称为分块（chunked）的传输方法。该方法使发送方能将消息实体分割为任意大小的组块（chunk），并单独地发送他们。在每个组块前面，都加上了该组块的长度，使接收方可确保自己能够完整地接收到这个组块。更重要的是，在最末尾的地方，发送方生成了长度为零的组块，接收方可据此判断整条消息都已安全地传输完毕。这样也避免了在服务器端占用大量的缓存。Transfer-Encoding ：chunked 向接收方指出：响应将被分组块，对响应分析时，应采取不同于非分组块的方式。

1. 状态码 100 Continue。

HTTP/1.1 加入了一个新的状态码 100 Continue，用于客户端在发送POST数据给服务器前，征询服务器的情况，看服务器是否处理POST的数据。当要 POST 的数据大于1024字节的时候，客户端并不会直接就发起POST请求, 而是会分为两步：

第一步， 发送一个请求, 包含一个 Expect:100-continue, 询问 Server 是否愿意接受数据。第二步，接收到 Server  返回的 100 continue 应答以后, 才把数据 POST 给 Server。

这种情况通常发生在客户端准备发送一个 冗长的请求给服务器，但是不确认服务器是否有能力接收。如果没有得到确认，而将一个冗长的请求包发送给服务器，然后包被服务器给抛弃了，这种情况挺浪费资源的。

1. Host域。

HTTP1.1在Request 消息头里多了一个 Host 域,HTTP1.0 则没有这个域。在 HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，这个IP地址上只有一个主机。但随着虚拟主机技术的发展，在一台物理服务器上可以存在 多个虚拟主机，并且它们共享一个IP地址。

• HTTP常用方法

并非所有的服务器都都实现了这几个方法。有的服务器还实现了自己特有 的HTTP方法，称为扩展方法。

1. GET

用于请求访问已经被URI（统一资源标识符）识别的资源，可以通过URL传参给服务器。

它本质就是发送一个请求来取得服务器上的某一资源。资源通过一组 HTTP 头和呈现数据（如HTML文本，或者图片或者视频等）返回给客户端。GET请求中，永远不会包含呈现数据。

1. HEAD

获得报文首部，与 GET 方法类似，只是不返回报文主体。

HEAD 和 GET 本质是一样的，区别在于 HEAD 不含有呈现数据，而仅仅是

HTTP 头信息。有的人可能觉得这个方法没什么用，其实不是这样的。想象一个业务情景：欲判断某个资源是否存在，我们通常使用 GET，但这里用 HEAD 则意义更加明确。

1. POST

用于传输信息给服务器，主要功能与 GET 方法类似，但一般推荐使用POST方式。向服务器提交数据。这个方法用途广泛，几乎目前所有的提交操作都是靠这个完成。

1. PUT

传输文件，报文主体中包含文件内容，保存到对应URI 位置。

这个方法比较少见。HTML 表单也不支持这个。本质上来讲， PUT 和 POST 极为相似，都是向服务器发送数据，但它们之间有一个重要区别，PUT 通常指定了资源的存放位置，而 POST 则没有，POST 的数据存放位置由服务器自己决定。举个例子：如一个用于提交博文的 URL，/addBlog。如果用 PUT，则提交的 URL 会是像这样的”/addBlog/abc123”，其中 abc123 就是这个博文的地址。而如果用 POST，则这个地址会在提交后由服务器告知客户端。目前大部分博客都是这样的。显然，PUT 和POST 用途是不一样的。具体用哪个还取决于当前的业务场景。

1. TRACE

请求服务器回送收到的请求信息，主要用于测试和诊断，所以是安全的。

1. OPTIONS

 查询相应 URL 支持的 HTTP 方法。

这个方法很有趣，但极少使用。它用于获取当前URL所支持的方法。若请求成功，则它会在HTTP头中包含一个名为“Allow”的头，值是所支持的方法，如“GET，POST”。

1. DELETE

 删除文件，与PUT方法相反，删除对应URI位置的文件。

删除某一个资源。基本上这个也很少见，不过还是有一些地方比如 amazon

的S3云服务里面就用的这个方法来删除资源。

1. 注意

HEAD、GET、OPTIONS 和 TRACE 视为安全的方法，因为它们只是从服务器获得资源而不对服务器做任何修改；但是 HEAD、GET、OPTIONS 在用户端不安全，而 POST则影响服务器上的资源。

GET 虽然不修改服务器数据，但是 GET 方法通过 URL 请求来传递用户的输入；HEAD只获得消息的头部，但是数据传入也是通过 URL。这样对客户端而言并不安全。

TRACE  方法对于服务端和用户端一定是安全的。

1. HTTP请求方式GET和POST的区别

1. GET 一般用于获取或者查询资源信息，这就意味着它是幂等的（对同一个 URL 的多个请求返回同样的结果）和安全的（没有修改资源的状态），而 POST 一般用于更新资源信息，POST 既不是安全的，也不是幂等的。
2. 采用 GET 方法时，客户端把要发送的数据添加到 URL 后面（就是把数据放置在HTTP 协议 头中，GET 是通过 URL 提交数据的），并且用“？”连接，各个变量之间用“&”连接；
3. HTTP 协议没有对 URL  长度进行限制，由于 特定的浏览器及服务器对 URL 的长度存在限制，所以传递的数据量有限；
4. 通过 GET 提交数据，用户名和密码将明文出现在 URL 上，因为(1)登录页面有可能被浏览器缓存，(2)其他人查看浏览器的“历史纪录”，那么别人就可以拿到你的账号和密码了。
5. 而 POST 把要传递的数据放到 HTTP 请求报文的 消息体中；HTTP 协议也没有进行大小限制，起限制作用的是服务器的处理程序的能力，但是，传送的数据量比 GET 方法更大些；由于传递的数据在消息体中，安全性高，但其实用抓包软件（如 httpwatch）进行抓包的话，可以看到传递的数据内容的。
6. GET请求的数据会被浏览器缓存起来，会留下历史记录；而 POST 提交的数据不会被浏览器缓存，不会留下历史记录。

• 为什么HTTP是无状态的？

无状态是指协议对于事务处理没有记忆能力，不能保存每次客户端提交的信息，即当服务器返回应答之后，这次事务的所有信息就都丢掉了。如果用户发来一个新的请求，服务器也无法知道它是否与上次的请求有联系。

这里我们用一个比较熟悉的例子来理解 HTTP 的无状态性，如一个包含多图片的网页的浏览。步骤为：①建立连接，客户端发送一个网页请求，服务器端返回一个html页面（这里的页面只是一个纯文本的页面，也就是我们写的html 代码），关闭连接；②浏览器解析html文件，遇到图片标记得到url，这时，客户端和服务器再建立连接，客户端发送一个图片请求，服务器返回图片应答，关闭连接。（这里又涉及到无状态定义：对于服务器来说，这次的请求虽然是同一个客户端的请求但是服务器还是不知道这个是之前的那个客户端，即对于事务处理没有记忆能力）。

优点：服务器不用为每个客户端连接 分配内存来记忆大量状态，也不用在客户端失去连接时去清理内存，节省服务器端资源，以更高效地去处理业务。

缺点：缺少状态意味着如果后续处理需要前面的信息，则客户端必须重传，这样可能导致每次连接传送的数据量增大。

• HTTP如何保持如何保持状态（会话跟踪技术、状态管理）

可以采用会话跟踪技术来解决这个问题。把状态保存在服务器中，只发送回一个标识符，浏览器在下次提交中把这个标识符发送过来；这样，就可以定位存储在服务器上的状态信息了。

会话跟踪技术共分为以下四种：

1. Cookie
2. Session
3. URL重写
4. 作为隐藏域嵌入HTML表单中（隐藏表单域）

在浏览器和服务器之间来回传递一个标识符，这就是所谓的会话（session）跟踪。来自浏览器的所有包含同一个标识符（这里是 SESSIONID）的请求同属于一个会话。

会话的有效期直到它被显式地终止为止，或者当用户在一段时间内没有动作，由服务器自动设置为过期。目前没有办法通知服务器用户已经关闭浏览器，因为在浏览器和服务器之间没有一个持久的连接，并且浏览器关闭时也不向服务器发送信息。同时，关闭浏览器通常意味着会话ID丢失，COOKIE将过期，或者注入了信息的URL将不能再使用。所以当用户再次打开浏览器的时候，服务器无法将新得到的请求与以前的会话联系起来则只能创建一个新的会话。然而，所有与前一个会话有关的数据依然存放在服务器上，直到会话过期被清除为止。

• HTTP短链接和长连接原理

HTTP 协议既可以实现长连接，也可以实现短连接。HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

在HTTP/1.0中，默认使用的是短连接。也就是说，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。如果客户端访问的某个HTML 或其他类型的Web页中包含有其他的Web资源，如JavaScript文件、图像文件、CSS文件等，当浏览器每遇到这样一个Web 资源，就会建立一个HTTP 会话。HTTP1.0需要在request中增加“Connection：keep-alive”header才能够支持长连接。

HTTP1.0 KeepAlive支持的数据交互流程如下：

1. Client发出request，其中该request的HTTP版本号为1.0。同时在request中包含一个header：“Connection：keep-alive”。
2.  Web Server收到request中的HTTP协议为1.0及“Connection：keep-alive”就认为是一个长连接请求，其将在response的header中也增加“Connection：keep-alive”。同时不会关闭已建立的 tcp 连接。
3.  Client 收到Web Server的response中包含“Connection：keep-alive”，就认为是一个长连接，不关闭tcp连接。并用该tcp连接再发送request。跳转到（1）。

但从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在请求头和响应头加入这行代码：“Connection：keep-alive”。

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接（http长连接利用同一个tcp连接处理多个http请求和响应）。但是Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接要客户端和服务器端都支持长连接。长连接中关闭连接通过Connection：closed头部字段。如果请求或响应中的Connection被指定为closed，表示在当前请求或响应完成后将关闭TCP连接。TCP的keep alive是检查当前TCP连接是否活着；HTTP的 Keep-alive是要让一个TCP 连接活久点。

HTTP1.1 KeepAlive支持的数据交互流程如下：

1. Client发出request，其中该request的HTTP版本号为1.1。
2. Web Server收到request中的HTTP协议为1.1就认为是一个长连接请求，其将在 response 的 header 中也增加“Connection：keep-alive”。同时不会关闭已建立的tcp连接。

1. Client收到Web Server的response中包含“Connection：keep-alive”，就认为是一个长连接，不关闭tcp连接，并用该tcp连接再发送request。跳转到（1）。

HTTP长连接的优点：①通过开启和关闭更少的TCP连接，节约CPU时间和内存。②通过减少TCP开启和关闭引起的包的数目，降低网络阻塞。

HTTP长连接的缺点：服务器维护一个长连接会增加开销。

HTTP短链接的优点：服务器不用为每个客户端连接分配内存来记忆大量状态，也不用在客户端失去连接时去清理内存，节省服务器端资源，以更高效地去处理业务。

HTTP短链接的缺点：如果客户请求频繁，将在TCP的建立和关闭操作上浪费时间和带宽。

• HTTP的特点

1. 支持客户端/ 服务器端通信模式。
2. 简单方便快速：当客户端向服务器端发送请求时，只是简单的填写请求路径和请求方法即可，然后就可以通过浏览器或其他方式将该请求发送就行了。比较常用的请求方法有三种，分别是：GET、HEAD、POST。不同的请求方法使得客户端和服务器端联系的方式各不相同。因为 HTTP 协议比较简单，所以 HTTP 服务器的程序规模相对比较小，从而使得通信的速度非常快。
3. 灵活：Http协议允许客户端和服务器端传输任意类型任意格式的数据对象。这些不同的类型由Content-Type标记。
4. 无连接：无连接的含义是每次建立的连接只处理一个客户端请求。当服务器处理完客户端的请求之后，并且收到客户的反馈应答后，服务器端立即断开连接。采用这种通信方式可以大大的节省传输时间。
5. 无状态：Http是无状态的协议。所谓的无状态是指协议对于请求的处理没有记忆功能。无状态意味着如果要再次处理先前的信息，则这些先前的信息必须要重传，这就导致了数据量传输的增加。但是从另一方面来说，当先前的信息服务器不在使用的时候，则服务器的响应将会非常的快。

• HTTP的安全问题

1. 通信使用明文不加密，内容可能被窃听。
2. 不验证通信方身份，可能遭到伪装。
3. 无法验证报文完整性，可能被篡改。

• HTTPS的概念与作用

HTTPS就是HTTP加上加密处理（一般是SSL安全通信线路）+认证+完整性保护。

HTTPS的作用主要有：

1. 内容加密。建立一个信息安全通道，来保证数据传输的安全；
2. 身份认证。身份认证 确认网站的真实性；
3. 数据完整性。防止内容被第三方冒充或者篡改。

• HTTP与HTTPS的区别

1. HTTPS更安全。HTTPS协议是由SSL+HTTP协议构建的可进行 加密传输、身份认证的网络协议，要比HTTP协议安全，所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。HTTP是超文本传输协议，信息是 明文传输，没有加密，通过抓包工具可以分析其信息内容。
2. HTTPS需要申请证书。HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费。而常见的HTTP协议则没有这一项。
3. 端口不同。HTTPS使用的是443端口，而HTTP使用的是80端口。
4. 所在层次不同。HTTP 协议运行在TCP之上，HTTPS 是运行在SSL/TLS之上的HTTP协议，SSL/TLS运行在TCP之上。

• 浏览器和服务器在基于HTTPS进行请求链接到数据传输过程中，用到了哪些技术？

1. 对称加密算法：用于对真正传输的数据进行加密。
2. 非对称加密算法：用于在握手过程中加密生成的密码。非对称加密算法会生成公钥和私钥，公钥只能用于加密数据，因此可以随意传输，而网站的私钥用于对数据进行解密，所以网站都会非常小心的保管自己的私钥，防止泄漏。
3. 散列算法：用户验证数据完整性。
4. 数字证书：数字证书其实就是一个小的计算机文件，其作用类似于我们的身份证、护照，用于证明身份，在SSL中，使用数字证书来证明自己的身份。
5. 客户端有公钥，服务器有私钥，客户端用公钥对`对称密钥`进行加密，将加密后的对称密钥发送给服务器，服务器用私钥对其进行解密，所以客户端和服务器可用对称密钥来进行通信。公钥和私钥是用来加密密钥，而对称密钥是用来加密数据，分别利用了两者的优点。

• http和socket的区别，两个协议哪个更高效一点

创建Socket连接时，可以指定使用的传输层协议，Socket可以支持不同的传输层协议（TCP或UDP），当使用TCP协议进行连接时，该Socket连接就是一个TCP连接。Socket连接一旦建立，通信双方即可开始相互发送数据内容，直到双方连接断开。注意，同HTTP不同的是HTTP只能基于TCP，Socket不仅能走Socket，而且还能走UDP，这个是Socket的第一个特点。

HTTP 连接使用的是“请求—响应”的方式，不仅在请求时需要先建立连接，而且需要客户端向服务器发出请求后，服务器端才能回复数据。

很多情况下，需要服务器端主动向客户端推送数据，保持客户端与服务器数据的实时与同步。此时若双方建立的是Socket连接，服务器就可以直接将数据传送给客户端；若双方建立的是 HTTP 连接，则服务器需要等到客户端发送一次请求后才能将数据传回给客户端。

Socket 效率高，至少不用解析HTTP报文头部一些字段。