计算机网络常见面试题总结

HTTP

概述

HTTP协议是基于TCP/IP协议之上的应用层协议。HTTP是一个无状态协议，在Web浏览器（客户端）和服务器之间不需要建立持久的连接，客户端发送请求，服务端返回响应后，一次通信结束，HTTP连接关闭，服务器不保留连接相关信息。
HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。
HTTP的传输流程包括地址解析，封装HTTP数据包、封装TCP包、建立TCP连接、客户端发送请求、服务端响应、服务端关闭TCP连接。

HTTP特点

• 支持客户/服务器模式。
• 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
• 灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type（Content-Type是HTTP包中用来表示内容类型的标识）加以标记。
• 无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
• 无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

HTTP 头部包含哪些信息？

HTTP 头部本质上是一个传递额外重要信息的键值对。主要分为：通用头部，请求头部，响应头部和实体头部。

通用头部

请求头部

响应头部

实体头部

如何知道 HTTP 的报文长度？

当响应消息中存在 Content-Length 字段时，我们可以直接根据这个值来判断数据是否接收完成，例如客户端向服务器请求一个静态页面或者一张图片时，服务器能够很清楚的知道请求内容的大小，因此可以通过消息首部字段 Content- Length 来告诉客户端需要接收多少数据，但是如果服务器预先不知道请求内容的大小，例如加载动态页面的时候，就需要使用 Transfer-Encoding: chunked 的方式来代替 Content-Length。

分块传输编码（Chunked transfer encoding）是 HTTP/1.1 中引入的一种数据传输机制，其允许 HTTP 由服务器发送给客户端的数据可以分成多个部分，当数据分解成一系列数据块发送时，服务器就可以发送数据而不需要预先知道发送内容的总大小，每一个分块包含十六进制的长度值和数据，最后一个分块长度值为0，表示实体结束，客户机可以以此为标志确认数据已经接收完毕。

HTTP请求报文

请求行：请求方式（post、get）、请求的资源（URL字段）、协议版本（HTTP/1.0：创建一次链接获得一个web资源，链接断开；HTTP/1.1：创建一个链接，获得多个web资源，保持连接）。

请求头：客户端发送给服务器端的一些信息，用键值对表示。包含：User-Agent：产生请求的浏览器类型。Accept：客户端可识别的内容类型列表。Host：主机地址。接受的编码方式和压缩方式。

常见的请求头字段含义：

• If-Modified-Since：当客户端访问页面时，服务器会将页面最后修改时间通过 Last-Modified 标识由服务器发往客户端，客户端记录修改时间，再次请求本地存在的cache页面时，客户端会通过 If-Modified-Since 头将先前服务器端发过来的最后修改时间戳发送回去，服务器端通过这个时间戳判断客户端的页面是否是最新的，如果不是最新的，则返回新的内容，如果是最新的，则 返回 304 告诉客户端其本地 cache 的页面是最新的，于是客户端就可以直接从本地加载页面了，这样在网络上传输的数据就会大大减少，同时也减轻了服务器的负担。
• If-None-Match：和响应头的 Etag 一起工作。当用户再次请求同个资源时，将上一次请求返回响应中的 Etag 值填入。如果服务器验证 Etag 没有改变，将返回304告诉客户端使用缓存。
• Pragma：防止页面被缓存。
• Cache-Control ：设置请求响应链上所有的缓存机制必须遵守的指令。
• Accept：客户端可以接受服务端发回的媒体类型。
• Accept-Charset：浏览器可接受的字符集。
• Accept-Encoding：浏览器能够进行解码的数据编码方式
• Accept-Language：浏览器所希望的语言种类，当服务器能够提供一种以上的语言版本时要用到。
• User-Agent：客户端使用的操作系统和浏览器版本。
• Content-Length：表示请求消息正文的长度。
• Referer：上下文信息。例如，如果在网页 1，点击一个链接到网页 2，当浏览器请求网页 2 时，网页 1 的 URL 就会包含在 Referer 头信息中。
• Cookie：客户机通过这个头可以向服务器带数据，这是最重要的请求头信息之一。
• Connection：处理完这次请求后是否断开连接还是继续保持连接。取值keep-alive代表建立长连接。如果Servlet看到这里的值为“Keep- Alive”，或者看到请求使用的是HTTP 1.1(HTTP 1.1默认进行持久连接)，它就可以利用持久连接的优点，当页面包含多个元素时(例如Applet，图片)，显著地减少下载所需要的时间。要实现这一点，Servlet需要在应答中发送一个Content-Length头，最简单的实现方法是：先把内容写入 ByteArrayOutputStream，然后在正式写出内容之前计算它的大小。
• Host：指定被请求资源的服务器IP和端口号。
• Range：用于请求头中，指定第一个字节的位置和最后一个字节的位置

消息主体：前台向后台发送的数据。当请求方式是post时，请求体会有请求参数，格式如下：username=zhangsan&password=123。
当请求方式是get时，请求参数不会出现在请求体中，会拼接在url地址后面： http://localhost:8080…？username=zhangsan&password=123。

HTTP响应报文

响应行：HTTP版本 + 状态码 + 状态代码的文本描述（状态描述）。常用状态码（200：请求成功；301：资源（网页等）被永久转移到其它URL；302：请求重定向；304：请求资源没有变，访问本地缓存；404：请求资源不存在；500：服务器内部错误）。

响应头：服务器端将信息以键值对的形式返回给客户端。包含服务器类型，日期，长度，内容类型等。

常见的响应头字段含义：

• Date：当前的GMT时间，例如：Date:Mon,31Dec200104:25:57GMT。
• Expires：浏览器会在指定过期时间内使用缓存。
• Content- Type：响应对象的类型和字符集。
• Content-Length：响应体长度。根据这个值来判断数据是否接收完成。
• Content-Encoding：响应体的编码方式以及是否压缩。
• Transfer-Encoding: WEB 服务器表明自己对本响应消息体（不是消息体里面的对象）作了怎样的编码，比如是否分块（chunked）。例如：Transfer-Encoding: chunked
• ETag ：和请求头中的If-None-Match配合使用。
• Last-Modified：文档的最后改动时间。客户可以通过If-Modified-Since请求头提供一个日期，该请求将被视为一个条件GET，只有改动时间迟于指定时间的文档才会返回，否则返回一个304(Not Modified)状态。
• Location：这个头配合302状态码使用，用于重定向接收者到一个新URI地址。表示客户应当到哪里去提取文档。Location通常不是直接设置的，而是通过 HttpServletResponse 的 sendRedirect 方法，该方法同时设置状态代码为302。
• Refresh：告诉浏览器隔多久刷新一次，以秒计。
• Content-Range：用于响应头中，在发出带 Range 的请求后，服务器会在 Content-Range 头部返回当前接受的范围和文件总大小。

响应体：是服务器回写给客户端的页面正文，浏览器将正文加载到内存，然后解析渲染，显示在页面内容。

响应状态码

状态代码由服务器发出，以响应客户端对服务器的请求。
1xx（信息）：收到请求，继续处理
2xx（成功）：请求已成功接收，理解和接受
3xx（重定向）：需要采取进一步措施才能完成请求
4xx（客户端错误）：请求包含错误的语法或无法满足
5xx（服务器错误）：服务器无法满足明显有效的请求

• 200 OK：表示从客户端发送给服务器的请求被正常处理并返回；
• 204 No Content：表示客户端发送给客户端的请求得到了成功处理，但在返回的响应报文中不含实体的主体部分（没有资源可以返回）；
• 206 Patial Content：表示客户端进行了范围请求，并且服务器成功执行了这部分的GET请求，响应报文中包含由Content-Range指定范围的实体内容。
• 301 Moved Permanently：永久性重定向，表示请求的资源被分配了新的URL，之后应使用更改的URL；
• 302 Found：临时性重定向，表示请求的资源被分配了新的URL，希望本次访问使用新的URL；
• 303 See Other：表示请求的资源被分配了新的URL，应使用GET方法定向获取请求的资源；
• 304 Not Modified：表示客户端发送附带条件（是指采用GET方法的请求报文中包含if-Match、If-Modified-Since、If-None-Match、If-Range、If-Unmodified-Since中任一首部）的请求时，服务器端允许访问资源，但是请求为满足条件的情况下返回改状态码；
• 307 Temporary Redirect：临时重定向，与303有着相同的含义，307会遵照浏览器标准不会从POST变成GET；（不同浏览器可能会出现不同的情况）；
• 400 Bad Request：表示请求报文中存在语法错误；
• 401 Unauthorized：未经许可，需要通过HTTP认证；
• 403 Forbidden：服务器拒绝该次访问
• 404 Not Found：表示服务器上无法找到请求的资源，也可以在服务器拒绝请求但不想给拒绝原因时使用；
• 500 Inter Server Error：表示服务器在执行请求时发生了错误；
• 503 Server Unavailable：表示服务器暂时处于超负载或正在进行停机维护，无法处理请求；

HTTP请求的方法

HTTP/1.0 定义了三种请求方法：GET, POST 和 HEAD 方法。
HTTP/1.1 增加了六种请求方法：OPTIONS, PUT, PATCH, DELETE, TRACE 和 CONNECT 方法。

请求方法的应用场景

GET：基于“URL”地址问号传参；一般用于向服务器获取资源，例如查询数据库的数据等；成功返回200。
POST：基于“请求”主体把消息发送给服务器；一般用于请求新增或修改资源，例如提交表单，新增用户等；先发送header，服务器响应100；再发送data，成功响应201。
PUT：修改资源。
DELETE：删除某个资源。
OPTIONS：一般是客户端向服务端判断对某个资源是否有访问权限。
HEAD：一般用于获取某个资源的metadata信息，比如说某份报告的关键描述信息等。

GET 和 POST 的区别

• get 提交的数据会放在 URL 之后，并且请求参数会被完整的保留在浏览器的记录里，由于参数直接暴露在 URL 中，可能会存在安全问题，因此往往用于获取资源信息。而 post 参数放在请求主体中，并且参数不会被保留，相比 get 方法，post 方法更安全，主要用于修改服务器上的资源。
• get 请求只支持 URL 编码，post 请求支持多种编码格式。
• get 只支持 ASCII 字符格式的参数，而 post 方法没有限制。
• get 提交的数据大小有限制（这里所说的限制是针对浏览器而言的），而 post 方法提交的数据没限制
• get 方式需要使用 Request.QueryString 来取得变量的值，而 post 方式通过 Request.Form 来获取。
• get 方法产生一个 TCP 数据包，post 方法产生两个（并不是所有的浏览器中都产生两个）。
  

GET 的长度限制是多少

HTTP 中的 GET 方法是通过 URL 传递数据的，而 URL 本身并没有对数据的长度进行限制，真正限制 GET 长度的是浏览器，例如 IE 浏览器对 URL 的最大限制为 2000多个字符，大概 2KB左右，像 Chrome, FireFox 等浏览器能支持的 URL 字符数更多，其中 FireFox 中 URL 最大长度限制为 65536 个字符，Chrome 浏览器中 URL 最大长度限制为 8182 个字符。并且这个长度不是只针对数据部分，而是针对整个 URL 而言，在这之中，不同的服务器同样影响 URL 的最大长度限制。因此对于特定的浏览器，GET的长度限制不同。

由于 POST 方法请求参数在请求主体中，理论上讲，post 方法是没有大小限制的，而真正起限制作用的是服务器处理程序的处理能力。

PUT和PATCH区别

PUT和PATCH都是用来修改服务端某个资源的，但是PUT和PATCH修改时提交的数据不同：PUT是将整个资源的信息都提交到服务端，包括修改的，未修改的都提交到服务端；而PATCH只提交已修改的字段到服务端。而服务端对PUT请求应该是整体替换，PATCH请求只修改提交的字段。所以PUT请求应该是幂等的，即多次提交同一个请求，结果是相同的。

Cookie && Session && Token

HTTP是无状态的，每次的请求都是独立的，它的执行情况与前后请求没有直接关系，它不会受前面的请求应答情况直接影响，也不会直接影响后面的请求应答情况。

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

客户端与服务器进行动态交互的Web应用程序出现之后，HTTP无状态的特性严重阻碍了这些应用程序的实现，毕竟交互是需要承前启后的，简单的购物车程序也要知道用户到底在之前选择了什么商品。于是，两种用于保持HTTP连接状态的技术就应运而生了，一个是Cookie，而另一个则是Session。HTTP本身是一个无状态的连接协议，为了支持客户端与服务器之间的交互，我们就需要通过不同的技术为交互存储状态，而这些不同的技术就是Cookie和Session了。

Cookie

Cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。
很多网站都会使用Cookie，Cookie具有不可跨域名性（所以不能实现单点登录）。

Session

Session是另一种记录客户状态的机制，不同的是Cookie保存在客户端浏览器中，而Session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。cookie中存放着session ID，请求时会发送这个ID，客户端再次访问时服务器只需要从Session中查找该客户的状态就可以了。

如果说Cookie机制是通过检查客户身上的“通行证”来确定客户身份的话，那么Session机制就是通过检查服务器上的“客户明细表”来确认客户身份。Session相当于程序在服务器上建立的一份客户档案，客户来访的时候只需要查询客户档案表就可以了。

注意

• cookie数据存放在客户的浏览器上，session数据放在服务器上。
• 单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。
• cookie只是实现session的其中一种方案。虽然是最常用的，但并不是唯一的方法。禁用cookie后还有其他方法存储，比如放在URL中
• 现在大多都是Session + Cookie，但是只用session不用cookie，或是只用cookie，不用session在理论上都可以保持会话状态。
• 用session只需要在客户端保存一个id，实际上大量数据都是保存在服务端。
• 如果只用cookie不用session，那么账户信息全部保存在客户端，一旦被劫持，全部信息都会泄露。并且客户端数据量变大，网络传输的数据量也会变大。
• Cookie只能存储字符串；
• 子域名可以获取顶级域名的Cookie

Token

互联网服务离不开用户认证。一般流程是下面这样：
1、用户向服务器发送用户名和密码。
2、服务器验证通过后，在当前对话（session）里面保存相关数据，比如用户角色、登录时间等等。
3、服务器向用户返回一个 session_id，写入用户的 Cookie。
4、用户随后的每一次请求，都会通过 Cookie，将 session_id 传回服务器。
5、服务器收到 session_id，找到前期保存的数据，由此得知用户的身份。

存在的问题：
1、每次用户发起请求时，服务器需要创建一个记录来存储信息。当越来越多的用户发请求时，内存的开销不断增大。
2、可扩展性不好。如果是服务器集群，或者是跨域的服务导向架构，就要求 session 数据共享，每台服务器都能够读取 session。
举例来说，A 网站和 B 网站是同一家公司的关联服务。现在要求，用户只要在其中一个网站登录，再访问另一个网站就会自动登录，请问怎么实现？

一种解决方案是 session 数据持久化，写入数据库或别的持久层。各种服务收到请求后，都向持久层请求数据。这种方案的优点是架构清晰，缺点是工程量比较大。另外，持久层万一挂了，就会单点失败。

另一种方案是服务器索性不保存 session 数据了，所有数据都保存在客户端，每次请求都发回服务器。
（1）客户端第一次请求时，发送用户信息到服务器。服务器对用户信息使用算法及密钥进行签名，再将这个签名和数据一起生成token返回给客户户端。
（2）服务端不再保存token，客户端保存token。
（3）当客户端再次发送请求时，在请求信息中将token一起发送给服务器。
（4）服务器用同样的算法和密钥，对数据再计算一次签名，和token的签名做比较。
（5）如果相同，服务器就知道客户端登录过，则反之。

Token就是一个令牌，无状态，用户信息都被加密到token中，服务器收到token后解密就可知道是哪个用户。需要开发者手动添加。

JWT(JSON Web Token)：跨域认证解决方案

JWT 的原理是，服务器认证以后，生成一个 JSON 对象，发回给用户，就像下面这样。

{
"姓名": "张三",
"角色": "管理员",
"到期时间": "2018年7月1日0点0分"
}

以后，用户与服务端通信的时候，都要发回这个 JSON 对象。服务器完全只靠这个对象认定用户身份。为了防止用户篡改数据，服务器在生成这个对象的时候，会加上签名。
服务器就不保存任何 session 数据了，也就是说，服务器变成无状态了，从而比较容易实现扩展。
一个JWT实际上就是一个字符串，它由三部分组成：头部、载荷与签名。

1、头部（Header）
头部用于描述关于该JWT的最基本的信息，例如其类型以及签名所用的算法等。这也可以被表示成一个JSON对象。

{
"typ":"JWT",
"alg":"HS256"
}

alg 属性表示签名的算法（algorithm），默认是 HMAC SHA256； typ 属性表示这个令牌（token）的类型（type），JWT 令牌统一写为 JWT 。
最后，将上面的 JSON 对象使用 Base64URL 算法转成字符串。

2、载荷（playload）
Payload 部分也是一个 JSON 对象，用来存放实际需要传递的数据。JWT 规定了7个官方字段，供选用。

iss: jwt签发者
sub: jwt所面向的用户
aud: 接收jwt的一方
exp: jwt的过期时间，这个过期时间必须要大于签发时间
nbf: 定义在什么时间之前，该jwt都是不可用的.
iat: jwt的签发时间
jti: jwt的唯一身份标识，主要用来作为一次性token。

除了官方字段，你还可以在这个部分定义私有字段，下面就是一个例子。

{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}

注意，JWT 默认是不加密的，任何人都可以读到，所以不要把秘密信息放在这个部分。
这个 JSON 对象也要使用 Base64URL 算法转成字符串。

3、签名（signature）
Signature 部分是对前两部分的签名，防止数据篡改。
首先，需要指定一个密钥（secret），这个密钥只有服务器才知道，不能泄露给用户。然后，使用Header 里面指定的签名算法，产生签名。算出签名以后，把 Header、Payload、Signature 三个部分拼成一个字符串，每个部分之间用.分隔，就可以返回给用户。

注意：secret是保存在服务器端的，Jwt的签发生成也是在服务器端的，secret就是用来进行Jwt的签发和Jwt的验证，所以，它就是你服务端的私钥，在任何场景都不应该流露出去。一旦客户端得知这个secret, 那就意味着客户端就可以自我签发Jwt了。

JWT特点：
（1）JWT 默认是不加密，但也是可以加密的。生成原始 Token 以后，可以用密钥再加密一次。
（2）JWT 不加密的情况下，不能将秘密数据写入 JWT。
（3）JWT 不仅可以用于认证，也可以用于交换信息。有效使用 JWT，可以降低服务器查询数据库的次数。
（4）JWT 的最大缺点是，由于服务器不保存 session 状态，因此无法在使用过程中废止某个 token，或者更改 token 的权限。也就是说，一旦 JWT 签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑。
（5）JWT 本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。为了减少盗用，JWT 的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。
（6）为了减少盗用，JWT 不应该使用 HTTP 协议明码传输，要使用 HTTPS 协议传输。

为什么要使用JWT：
分布式系统解决Session问题。
假设现在有一个APP，后台是分布式系统。APP的首页模块部署在杭州机房的服务器上，子页面模块部署在深圳机房的服务器上。此时你从首页登录了该APP，然后跳转到子页面模块。session在两个机房之间不能同步，用户是否需要重新登录？传统的方式（cookie+session）需要重新登录，用户体验不好。session共享（在多台物理机之间传输和复制session）方式对网络IO的压力大，延迟太长，用户体验也不好。JWT相当于将session保存在了客户端，解决了后台session复制的问题。

分布式session解决方案

1、session复制
session复制是早期的企业级的使用比较多的一种服务器集群session管理机制。应用服务器开启web容器的session复制功能，在集群中的几台服务器之间同步session对象，使得每台服务器上都保存所有的session信息，这样任何一台宕机都不会导致session的数据丢失，服务器使用session时，直接从本地获取。

这种方式在应用集群达到数千台的时候，就会出现瓶颈，每台都需要备份session，出现内存不够用的情况。

2、session绑定
利用hash算法，比如nginx的ip_hash,使得同一个IP的请求分发到同一台服务器上。

这种方式不符合对系统的高可用要求，因为一旦某台服务器宕机，那么该机器上的session也就不复存在了，用户请求切换到其他机器后没有session，无法完成业务处理。

3、利用cookie记录session
session记录在客户端，每次请求服务器的时候，将session放在请求中发送给服务器，服务器处理完请求后再将修改后的session响应给客户端。这里的客户端就是cookie。

利用cookie记录session的也有缺点，比如受cookie大小的限制，能记录的信息有限；每次请求响应都需要传递cookie，影响性能，如果用户关闭cookie，访问就不正常。

4、Session集中式存储
将原先存储在单机服务器内存中的Session数据集中存储起来，比如说存储在分布式缓存 Redis 集群中。

其原理是以SessionId作为Key，序列化后的HttpSession对象作为Value存储在Redis中，然后将SessionId返回给客户端，当下一次客户端发送HTTP请求到服务器的时候，会带上这个SessionId，服务器再根据SessionId从Redis拿到相应的Session数据并反序列化成HttpSession对象。由于对HttpSession对象进行了集中存储，而不是存储在服务器本地内存，所以即使同个用户的多次HTTP请求落到不同的服务器上，也能将SessionId与相应的HttpSession对象关联起来，从而实现分布式环境下的Session共享。

HTTP 是不保存状态的协议,如何保存用户状态？

假如某个特定的客户机在短时间内两次请求同一个对象，服务器并不会因为刚刚为该用户提供了该对象就不再做出反应，而是重新发送该对象，就像该服务器已经完全忘记不久之前所做过的是一样。因为一个 HTTP 服务器并不保存关于客户机的任何信息，所以我们说 HTTP 是一个无状态协议。

通常有两种解决方案：
（1）基于 Session 实现的会话保持
在客户端第一次向服务器发送 HTTP 请求后，服务器会创建一个 Session 对象并将客户端的身份信息以键值对的形式存储下来，然后分配一个会话标识（SessionId）给客户端，这个会话标识一般保存在客户端 Cookie 中，之后每次该浏览器发送 HTTP 请求都会带上 Cookie 中的 SessionId 到服务器，服务器根据会话标识就可以将之前的状态信息与会话联系起来，从而实现会话保持。

优点：安全性高，因为状态信息保存在服务器端。
缺点：由于大型网站往往采用的是分布式服务器，浏览器发送的 HTTP 请求一般要先通过负载均衡器才能到达具体的后台服务器，倘若同一个浏览器两次 HTTP 请求分别落在不同的服务器上时，基于 Session 的方法就不能实现会话保持了。

【解决方法：采用中间件，例如 Redis，我们通过将 Session 的信息存储在 Redis 中，使得每个服务器都可以访问到之前的状态信息】

（2）基于 Cookie 实现的会话保持
当服务器发送响应消息时，在 HTTP 响应头中设置 Set-Cookie 字段，用来存储客户端的状态信息。客户端解析出 HTTP 响应头中的字段信息，并根据其生命周期创建不同的 Cookie，这样一来每次浏览器发送 HTTP 请求的时候都会带上 Cookie 字段，从而实现状态保持。基于 Cookie 的会话保持与基于 Session 实现的会话保持最主要的区别是前者完全将会话状态信息存储在浏览器 Cookie 中。

优点：服务器不用保存状态信息， 减轻服务器存储压力，同时便于服务端做水平拓展。
缺点：该方式不够安全，因为状态信息存储在客户端，这意味着不能在会话中保存机密数据。除此之外，浏览器每次发起 HTTP 请求时都需要发送额外的 Cookie 到服务器端，会占用更多带宽。

拓展：Cookie被禁用了怎么办？
若遇到 Cookie 被禁用的情况，则可以通过重写 URL 的方式将会话标识放在 URL 的参数里，也可以实现会话保持。

HTTP/1.1 和 HTTP/1.0 的区别

• 缓存处理：在 HTTP/1.0 中主要使用 header 里的 if-modified-Since, Expries 来做缓存判断的标准。而 HTTP/1.1 请求头中添加了更多与缓存相关的字段，从而支持更为灵活的缓存策略，例如 Entity-tag, If-Unmodified-Since, If-Match, If-None-Match 等可供选择的缓存头来控制缓存策略。
• 节约带宽： 当客户端请求某个资源时，HTTP/1.0 默认将该资源相关的整个对象传送给请求方，但很多时候可能客户端并不需要对象的所有信息。而在 HTTP/1.1 的请求头中引入了 range 头域，它允许只请求部分资源，其使得开发者可以多线程请求某一资源，从而充分的利用带宽资源，实现高效并发。
• 错误通知的管理：HTTP/1.1 在 1.0 的基础上新增了 24 个错误状态响应码，例如 414 表示客户端请求中所包含的 URL 地址太长，以至于服务器无法处理；410 表示所请求的资源已经被永久删除。
• Host 请求头：早期 HTTP/1.0 中认为每台服务器都绑定一个唯一的 IP 地址并提供单一的服务，请求消息中的 URL 并没有传递主机名。而随着虚拟主机的出现，一台物理服务器上可以存在多个虚拟主机，并且它们共享同一个 IP 地址。为了支持虚拟主机，HTTP/1.1 中添加了 host 请求头，请求消息和响应消息中应声明这个字段，若请求消息中缺少该字段时服务端会响应一个 404 错误状态码。
• 长连接：HTTP/1.0 默认浏览器和服务器之间保持短暂连接，浏览器的每次请求都需要与服务器建立一个 TCP 连接，服务器完成后立即断开 TCP 连接。HTTP/1.1 默认使用的是持久连接，其支持在同一个 TCP 请求中传送多个 HTTP 请求和响应。此之前的 HTTP 版本的默认连接都是使用非持久连接，如果想要在旧版本的 HTTP 协议上维持持久连接，则需要指定 Connection 的首部字段的值为 Keep-Alive。

HTTP 1.1如何断点续传？

HTTP 1.1协议中定义了断点续传相关的HTTP头 Range和Content-Range字段，一个最简单的断点续传实现大概如下：

1. 客户端下载一个1024K的文件，已经下载了其中512K
2. 网络中断，客户端请求续传，因此需要在HTTP头中申明本次需要续传的片段：
   Range:bytes=512000-
   这个头通知服务端从文件的512K位置开始传输文件
3. 服务端收到断点续传请求，从文件的512K位置开始传输，并且在HTTP头中增加：
   Content-Range:bytes 512000-/1024000
   并且此时服务端返回的HTTP状态码应该是206，而不是200。

但是在实际场景中，会出现一种情况，即在终端发起续传请求时，URL对应的文件内容在服务端已经发生变化，此时续传的数据肯定是错误的。如何解决这个问题？显然此时我们需要有一个标识文件唯一性的方法。
在 RFC2616 中也有相应的定义，比如实现 Last-Modified 来标识文件的最后修改时间，这样即可判断出续传文件时是否已经发生过改动。同时 FC2616 中还定义有一个 ETag 的头，可以使用 ETag 头来放置文件的唯一标识。

If-Modified-Since，和 Last-Modified 一样都是用于记录页面最后修改时间的 HTTP 头信息，只是 Last-Modified 是由服务器往客户端发送的 HTTP 头，而 If-Modified-Since 则是由客户端往服务器发送的头，可以看到，再次请求本地存在的 cache 页面时，客户端会通过 If-Modified-Since 头将先前服务器端发过来的 Last-Modified 最后修改时间戳发送回去，这是为了让服务器端进行验证，通过这个时间戳判断客户端的页面是否是最新的，如果不是最新的，则返回新的内容，如果是最新的，则返回 304 告诉客户端其本地 cache 的页面是最新的，于是客户端就可以直接从本地加载页面了，这样在网络上传输的数据就会大大减少，同时也减轻了服务器的负担。

Etag（Entity Tags）主要为了解决 Last-Modified 无法解决的一些问题。

1. 一些文件也许会周期性的更改，但是内容并不改变（仅改变修改时间），这时候我们并不希望客户端认为这个文件被修改了，而重新 GET。
2. 某些文件修改非常频繁，例如：在秒以下的时间内进行修改（1s 内修改了 N 次），If-Modified-Since 能检查到的粒度是 s 级的，这种修改无法判断（或者说 UNIX 记录 MTIME 只能精确到秒）。
3. 某些服务器不能精确的得到文件的最后修改时间。

为此，HTTP/1.1 引入了 Etag。Etag 仅仅是一个和文件相关的标记。

另外RFC2616中同时定义有一个If-Range头，终端如果在续传是使用If-Range。If-Range中的内容可以为最初收到的ETag头或者是Last-Modfied中的最后修改时候。服务端在收到续传请求时，通过If-Range中的内容进行校验，校验一致时返回206的续传回应，不一致时服务端则返回200回应，回应的内容为新的文件的全部数据。

第一次请求：

1. 客户端发起 HTTP GET 请求一个文件。
2. 服务器处理请求，返回文件内容以及相应的 Header，其中包括 Etag（例如：627-4d648041f6b80）（假设服务器支持 Etag 生成并已开启了 Etag）状态码为 200。

第二次请求（断点续传）：

1. 客户端发起 HTTP GET 请求一个文件，同时发送 If-Range（该头的内容就是第一次请求时服务器返回的 Etag：627-4d648041f6b80）。
2. 服务器判断接收到的 Etag 和计算出来的 Etag 是否匹配，如果匹配，那么响应的状态码为 206；否则，状态码为 200。

HTTP 1.x的缺陷

• 客户端需要使用多个连接才能实现并发和缩短延迟；
• 不会压缩请求和响应首部，从而导致不必要的网络流量；
• 不支持有效的资源优先级，致使底层 TCP 连接的利用率低下。

SPDY

HTTP1.x的优化：优化了HTTP1.X的请求延迟，解决了HTTP1.X的安全性问题。

• 降低延迟，针对HTTP高延迟的问题，SPDY优雅的采取了多路复用（multiplexing），降低了延迟同时提高了带宽的利用率。多路复用通过多个请求stream共享一个TCP连接的方式，解决了HOL blocking的问题。
• 请求优先级（request prioritization）。多路复用带来一个新的问题是，在连接共享的基础上可能会导致关键请求被阻塞。SPDY允许给每个request设置优先级，这样重要的请求就会优先得到响应。比如浏览器加载首页，首页的html内容应该优先展示，之后才是各种静态资源文件，脚本文件等加载，这样可以保证用户能第一时间看到网页内容。
• header压缩。前面提到HTTP1.x的header很多时候都是重复多余的。选择合适的压缩算法可以减小包的大小和数量。
• 基于HTTPS的加密协议传输，大大提高了传输数据的可靠性。
• 服务端推送（server push），采用了SPDY的网页，例如我的网页有一个sytle.css的请求，在客户端收到sytle.css数据的同时，服务端会将sytle.js的文件推送给客户端，当客户端再次尝试获取sytle.js时就可以直接从缓存中获取到，不用再发请求了。
  SPDY在HTTP之下，TCP和SSL之上，可以轻松兼容老版本HTTP协议(将HTTP1.x内容封装成一种新的frame格式)，同时可以使用已有的SSL功能。

HTTP2.0：SPDY的升级版，区别如下：

• HTTP2.0 支持明文 HTTP 传输，而 SPDY 强制使用 HTTPS；
• HTTP2.0 消息头的压缩算法采用HPACK，而SPDY 采用DEFLATE。

HTTP/1.X 和 HTTP/2.0 的区别

• 相比于 HTTP/1.X 的文本（字符串）传送， HTTP/2.0 采用二进制传送。客户端和服务器传输数据时把数据分成帧，帧组成了数据流，流具有流 ID 标识和优先级，通过优先级以及流依赖能够一定程度上解决关键请求被阻塞的问题。
• HTTP/2.0 支持多路复用。因为流 ID 的存在， 通过同一个 HTTP 请求可以实现多个 HTTP 请求传输，客户端和服务器可以通过流 ID 来标识究竟是哪个流从而定位到是哪个 HTTP 请求。
• HTTP/2.0 头部压缩。HTTP/2.0 通过 gzip 和 compress 压缩头部然后再发送，同时通信双方会维护一张头信息表，所有字段都记录在这张表中，在每次 HTTP 传输时只需要传头字段在表中的索引即可，大大减小了重传次数和数据量。
• HTTP/2.0 支持服务器推送。 服务器在客户端未经请求许可的情况下，可预先向客户端推送需要的内容，客户端在退出服务时可通过发送复位相关的请求来取消服务端的推送。

HTTP2.0的多路复用和HTTP1.X中的长连接复用有什么区别？

HTTP/1.0 一次请求-响应，建立一个连接，用完关闭；每一个请求都要建立一个连接；
HTTP/1.1 所有的数据通信是按次序进行的。服务器只有处理完一个请求，才会接着处理下一个请求。一旦有某请求超时等，后续请求只能被阻塞，也就是人们常说的线头/端/程阻塞；
HTTP/2.0多个请求可同时在一个连接上并行执行。某个请求任务耗时严重，不会影响到其它连接的正常执行。

HTTP/3

HTTP/2 存在的问题

我们知道，传统 Web 平台的数据传输都基于 TCP 协议，而 TCP 协议在创建连接之前不可避免的需要三次握手，如果需要提高数据交互的安全性，即增加传输层安全协议（TLS），还会增加更多的握手次数。HTTP 从 1.0 到 2.0，其传输层都是基于 TCP 协议的。即使是带来巨大性能提升的 HTTP/2，也无法完全解决 TCP 协议存在的固有问题（慢启动，拥塞窗口尺寸的设置等）。此外，HTTP/2 多路复用只是减少了连接数，其队头的拥塞问题并没有完全解决，倘若 TCP 丢包率过大，则 HTTP/2 的表现将不如 HTTP/1.1。

QUIC 协议

QUIC（Quick UDP Internet Connections），直译为快速 UDP 网络连接，是谷歌制定的一种基于 UDP 的低延迟传输协议。其主要目的是解决采用传输层 TCP 协议存在的问题，同时满足传输层和应用层对多连接、低延迟等的需求。该协议融合了 TCP, TLS, HTTP/2 等协议的特性，并基于 UDP传输。该协议带来的主要提升有：

• 低延迟连接。当客户端第一次连接服务器时，QUIC 只需要 1 RTT（Round-Trid Time）延迟就可以建立安全可靠的连接（采用 TLS 1.3 版本），相比于 TCP + TLS 的 3 次 RTT 要更加快捷。之后，客户端可以在本地缓存加密的认证信息，当再次与服务器建立连接时可以实现 0 RTT 的连接建立延迟。
• QUIC 复用了 HTTP/2 协议的多路复用功能，由于 QUIC 基于 UDP，所以也避免了 HTTP/2存在的队头阻塞问题。
• 基于 UDP 协议的 QUIC 运行在用户域而不是系统内核，这使得 QUIC 协议可以快速的更新和部署，从而很好地解决了 TPC 协议部署及更新的困难。
• QUIC 的报文是经过加密和认证的，除了少量的报文，其它所有的 QUIC 报文头部都经过了认证，报文主体经过了加密。只要有攻击者篡改 QUIC 报文，接收端都能及时发现。
• 具有向前纠错机制，每个数据包携带了除了本身内容外的部分其他数据包的内容，使得在出现少量丢包的情况下，尽量地减少其它包的重传次数，其通过牺牲单个包所携带的有效数据大小换来更少的重传次数，这在丢包数量较小的场景下能够带来一定程度的性能提升。

HTTP/3

HTTP/3 是在 QUIC 基础上发展起来的，其底层使用 UDP 进行数据传输，上层仍然使用 HTTP/2。在 UDP 与 HTTP/2 之间存在一个 QUIC 层，其中 TLS 加密过程在该层进行处理。HTTP/3 主要有以下几个特点：

• 使用 UDP 作为传输层进行通信；
• 在 UDP 之上的 QUIC 协议保证了 HTTP/3 的安全性。QUIC 在建立连接的过程中就完成了 TLS 加密握手；
• 建立连接快，正常只需要 1 RTT 即可建立连接。如果有缓存之前的会话信息，则直接验证和建立连接，此过程 0 RTT。建立连接时，也可以带有少量业务数据；
• 不和具体底层连接绑定，QUIC 为每个连接的两端分别分配了一个唯一 ID，上层连接只认这对逻辑 ID。网络切换或者断连时，只需要继续发送数据包即可完成连接的建立；
• 使用 QPACK 进行头部压缩，因为 在 HTTP/2 中的 HPACK 要求传输过程有序，这会导致队头阻塞，而 QPACK 不存在这个问题。
  最后我们使用一张图来清晰的表示出 HTTP 协议的发展变化：
  

短链接和长链接的区别

所谓长连接，指在一个TCP连接上可以连续发送多个数据包，在TCP连接保持期间，如果没有数据包发送，需要双方发检测包以维持此连接，一般需要自己做在线维持。

短连接是指通信双方有数据交互时，就建立一个TCP连接，数据发送完成后，则断开此TCP连接，一般银行都使用短连接。HTTP是无状态的的短链接。

HTTP 长连接短连接使用场景是什么

长连接：多用于操作频繁，点对点的通讯，而且客户端连接数目较少的情况。例如即时通讯、网络游戏等。

短连接：用户数目较多的Web网站的 HTTP 服务一般用短连接。例如京东，淘宝这样的大型网站一般客户端数量达到千万级甚至上亿，若采用长连接势必会使得服务端大量的资源被无效占用，所以一般使用的是短连接。

Keep-Alive 和非 Keep-Alive 区别，对服务器性能有影响吗？

在早期的 HTTP/1.0 中，浏览器每次 发起 HTTP 请求都要与服务器创建一个新的 TCP 连接，服务器完成请求处理后立即断开 TCP 连接，服务器不跟踪每个客户也不记录过去的请求。然而创建和关闭连接的过程需要消耗资源和时间，为了减少资源消耗，缩短响应时间，就需要重用连接。在 HTTP/1.1 版本中默认使用持久连接，在此之前的 HTTP 版本的默认连接都是使用非持久连接，如果想要在旧版本的 HTTP 协议上维持持久连接，则需要指定 connection 的首部字段的值为 Keep-Alive 来告诉对方这个请求响应完成后不要关闭，下一次咱们还用这个请求继续交流，我们用一个示意图来更加生动的表示两者的区别：

对于非 Keep-Alive 来说，必须为每一个请求的对象建立和维护一个全新的连接。对于每一个这样的连接，客户机和服务器都要分配 TCP 的缓冲区和变量，这给服务器带来的严重的负担，因为一台 Web 服务器可能同时服务于数以百计的客户机请求。在 Keep-Alive 方式下，服务器在响应后保持该 TCP 连接打开，在同一个客户机与服务器之间的后续请求和响应报文可通过相同的连接进行传送。甚至位于同一台服务器的多个 Web 页面在从该服务器发送给同一个客户机时，可以在单个持久 TCP 连接上进行。

然而，Keep-Alive 并不是没有缺点的，当长时间的保持 TCP 连接时容易导致系统资源被无效占用，若对 Keep-Alive 模式配置不当，将有可能比非 Keep-Alive 模式带来的损失更大。因此，我们需要正确地设置 keep-alive timeout 参数，当 TCP 连接在传送完最后一个 HTTP 响应，该连接会保持 keepalive_timeout 秒，之后就开始关闭这个链接。

HTTP与TCP的区别？

TCP/IP是一个分层的协议，计算机里面很多东西都是这样分层来设计的，这样设计的好处是每一层只需要考虑自己需要处理的数据。
在TCP/IP协议的四层模型里，HTTP属于应用层，之所以叫应用层是因为这些是我们直接接触到的具体应用，比如用于网页浏览的HTTP，用于传输文件的FTP，或者远程登录的Telnet和SSH。HTTP是无状态的短连接。
TCP是传输层，它通过流量控制、重传等机制来在主机间建立一个可靠的连接。TCP使用不同的端口来标记不同的应用发起的连接。为了避免在网络层产生分片，TCP会通过协商MSS，Path MTU Discovery的方式来对数据包进行分段交给网络层。TCP是有状态的长连接。
IP是网络层，负责处理不同的网络之间发送的数据包，它不需要考虑具体应用或者端口的信息。它的主要工作是分片（fragmentation）和重组（reassembly）数据包以及根据IP地址做路由（route）。TCP需要通过重传来保证可靠性，所以不依赖网络层的分片，主要是UDP使用。
总结：

• IP是网络层，负责把包从发送端送到接收端，但是，不保证服务（丢、多、改、按序）；
• TCP是传输层，是底层通讯协议，定义的是数据传输和连接方式的规范，负责可靠传输，保证HTTP层能拿到正确格式的包；
• HTTP是应用层协议，定义的是传输数据的内容的规范，负责内容解析、内容呈现、用户交互；
• HTTP一般基于TCP，TCP一般基于IP。三者之间是服务关系。HTTP:发什么；TCP:怎么发；IP:发数据给谁。

URI && URL

• URI(Uniform Resource Identifier) 是统一资源标志符，可以唯一标识一个资源。不是定位资源
• URL(Uniform Resource Location) 是统一资源定位符，可以提供该资源的路径。它是一种具体的URI，即 URL 可以用来标识一个资源，而且还指明了如何 locate 这个资源。其实就是我们平时上网时输入的网址，它标识一个互联网资源，并指定对其进行操作或获取该资源的方法。例如 https://leetcode-cn.com/problemset/all/ 这个 URL，标识一个特定资源并表示该资源的某种形式是可以通过 HTTP 协议从相应位置获得。
• URN(Uniform Resource Name)统一资源名。

URI的作用像身份证号一样，URN如同一个人的名称，URL的作用更像家庭住址一样。URL是一种具体的URI，它不仅唯一标识资源，而且还提供了定位该资源的信息。

URL 是 URI 的一个子集，两者都定义了资源是什么，而 URL 还定义了如何能访问到该资源。URI 是一种语义上的抽象概念，可以是绝对的，也可以是相对的，而URL则必须提供足够的信息来定位，是绝对的。简单地说，只要能唯一标识资源的就是 URI，在 URI 的基础上给出其资源的访问方式的就是 URL。

HTTPS

什么是 HTTPS？

HTTPS，是以安全为目标的HTTP通信，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。 现在它被广泛用于万维网上安全敏感的通讯，例如交易支付方面。经常会在Web的登录页面和购物结算界面等使用HTTPS通信（当浏览器访问HTTPS通信有效的Web网站时，浏览器的地址栏内会出现一个带锁的标记）。

HTTPS 并不是新协议，而是让 HTTP 先和 SSL （Secure Sockets Layer）通信，再由 SSL 和 TCP 通信，也就是说 HTTPS 使用了隧道进行通信。通过使用 SSL，HTTPS 具有了加密（防窃听）、认证（防伪装）和完整性保护（防篡改）。

HTTPS工作原理

• 发起请求

客户端通过TCP和服务器建立连接后（443端口），发出请求证书的消息，此消息里包含自己可实现的算法列表。

• 证书返回

采用 HTTPS 协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请，区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面。这套证书其实就是一对公钥和私钥。是用来进行非对称加密使用的，服务器端保存着私钥，不能将其泄露，公钥可以发送给任何人；

服务器端收到消息后，返回公钥。公钥包含了很多信息，如证书的颁发机构，过期时间、数据等等。

• 证书验证

客户端收到服务器端的公钥之后，检查其合法性，比如颁发机构，过期时间等等，如果发现发现公钥有问题，那么HTTPS传输就无法继续。

如果公钥合格，则客户端会生成一个客户端密钥，然后用服务器的公钥对客户端密钥进行非对称加密成密文，至此，HTTPS中的第一次HTTP请求结束；

• 秘钥交换

客户端发起HTTPS中的第二个HTTP请求，将加密之后的客户端密钥发送给服务器；

服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后的明文就是客户端密钥，然后用客户端密钥对数据进行对称加密，这样数据就变成了密文；然后服务器将加密后的密文发送给客户端；

• 数据传输

客户端收到服务器发送来的密文，用客户端密钥对其进行对称解密，得到服务器发送的数据。这样HTTPS中的第二个HTTP请求结束，整个HTTPS传输完成。

HTTP 与 HTTPS 的区别

• HTTP 运行在TCP之上，是明文传输；连接很简单，是无状态的。HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，可进行加密传输、身份认证，比 HTTP 协议安全；
• HTTP和 HTTPS 使用的是完全不同的连接方式，用的端口也不一样，HTTP 的端口号是 80，HTTPS 是 443；
• HTTPS 需要到 CA 申请证书，一般免费证书很少，需要交费。
• HTTP 页面响应速度比 HTTPS 快，主要是因为 HTTP 使用 TCP 三次握手建立连接，客户端和服务器需要交换 3 个包，而 HTTPS除了 TCP 的三个包，还要加上 ssl 握手需要的 9 个包，所以一共是12 个包。
• HTTPS 其实就是建构在 SSL/TLS 之上的 HTTP 协议，所以，要比较 HTTPS 比 HTTP 要更耗费服务器资源。

HTTP通信存在什么问题?

• 通信使用明文（不加密），内容可能被窃听

HTTP本身不具备加密的功能，所以也无法做到对通信整体（使用HTTP协议通信的请求和响应的内容）进行加密。即，HTTP报文使用明文（指未经过加密的报文）方式发送。

• 不验证通信方的身份，因此有可能遭遇伪装

HTTP协议中的请求和响应不会对通信方进行确认（会存在各种隐患，比如目标的Web服务器有可能是已伪装的Web服务器）。在HTTP协议通信时，由于不存在确认通信方的处理步骤，任何人都可以发起请求。另外，服务器只要接收到请求，不管对方是谁都会返回一个响应（但也仅限于发送端的IP地址和端口号没有被Web服务器设定限制访问的前提下）。

• 无法证明报文的完整性，所以可能遭篡改

所谓完整性是指信息的准确度。若无法证明其完整性，通常也就意味着无法判断信息是否准确。由于HTTP协议无法证明通信的报文完整性，因此，在请求或响应送出之后直到对方接收之前的这段时间内，即使请求或响应的内容遭到篡改，也没有办法获悉。

HTTPS如何解决上述三个问题？

HTTPS并非是应用层的一种新协议。只是HTTP通信接口部分用SSL（Secure Socket Layer）和TLS（Transport Layer Security）协议代替而已。

通常，HTTP直接和TCP通信。当使用SSL时，则演变成先和SSL通信，再由SSL和TCP通信了。所谓HTTPS，其实就是身披SSL协议外壳的HTTP。

在采用SSL后，HTTP就拥有了HTTPS的加密、身份验证和完整性保护这些功能。也就是说HTTP加上加密处理、认证以及完整性保护后即是HTTPS。

加密算法

HTTPS 协议的主要功能基本都依赖于 TLS/SSL 协议，TLS/SSL 的功能实现主要依赖于三类基本算法：散列算法、对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列算法验证信息的完整性。

非对称加密算法：RSA，DSA/DSS，ECC

对称加密算法：AES，RC4，3DES，DES

散列算法（HASH算法）：MD5，SHA1，SHA256

加密——解决内容可能被窃听的问题

对称加密：
这种方式加密和解密同用一个密钥。没有密钥就无法进行解密，反过来说，任何人只要持有密钥就能解密了。

非对称加密：
非对称加密/公开密钥加密 使用一对非对称的密钥。一把叫做私有密钥，另一把叫做公开密钥。顾名思义，私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。
非对称加密的特点是信息传输一对多，服务器只需要维持一个私钥就能够和多个客户端进行加密通信，但服务器发出的信息能够被所有的客户端解密，且该算法的计算复杂，加密速度慢。

对称加密+非对称加密：
将对称加密与非对称加密结合起来,充分利用两者各自的优势，将多种方法组合起来用于通信。在交换密钥环节使用非对称加密方式，之后的建立通信交换报文阶段则使用对称加密方式。具体做法是：发送密文的一方使用对方的公钥对“对称的密钥”进行加密，然后对方用自己的私钥解密拿到“对称的密钥”，这样可以确保交换的密钥是安全的前提下，使用对称加密方式进行通信。所以，HTTPS采用对称加密和非对称加密两者并用的混合加密机制。

数字签名——解决报文可能遭篡改问题

数字签名有两种功效：

• 能确定消息确实是由发送方签名并发出来的，因为发送方签名无法伪造。
• 数字签名能验证消息的完整性，证明数据是否未被篡改过。

数字签名技术就是对“非对称密钥加解密”和“数字摘要“两项技术的应用，它将摘要信息用发送者的私钥加密，与原文一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的摘要信息。然后用HASH函数对收到的原文产生一个摘要信息，与解密的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改；否则说明信息被修改过。

认证——解决通信方身份可能被伪装的问题

非对称加密方式还是存在一些问题的。那就是无法证明公开密钥本身就是货真价实的公开密钥。为了解决上述问题，可以使用由数字证书认证机构（CA，Certificate Authority）和其相关机关颁发的公开密钥证书，也可叫做数字证书或直接称为证书。

接到证书的客户端可使用数字证书认证机构的公开密钥，对那张证书上的数字签名进行验证，一旦验证通过，客户端便可明确两件事：一，认证服务器的公开密钥的是真实有效的数字证书认证机构。二，服务器的公开密钥是值得信赖的。

为什么不一直使用HTTPS

与纯文本通信相比，加密通信会消耗更多的CPU及内存资源。如果每次通信都加密，会消耗相当多的资源，平摊到一台计算机上时，能够处理的请求数量必定也会随之减少。如果是非敏感信息则使用HTTP通信，只有在包含个人信息等敏感数据时，才利用HTTPS加密通信。

想要节约购买证书的开销也是原因之一。

DNS

DNS 的作用和原理

DNS：（Domain Name System）是域名系统的英文缩写，是一种组织成域层次结构的计算机和网络服务命名系统，用于 TCP/IP 网络。

DNS 的作用：通常我们有两种方式识别主机：通过主机名或者 IP 地址。人们喜欢便于记忆的主机名表示，而路由器则喜欢定长的、有着层次结构的 IP 地址。为了满足这些不同的偏好，我们就需要一种能够进行主机名到 IP 地址转换的目录服务，域名系统作为将域名和 IP 地址相互映射的一个分布式数据库，能够使人更方便地访问互联网。

DNS 域名解析原理：DNS 采用了分布式的设计方案，其域名空间采用一种树形的层次结构：

上图展示了 DNS 服务器的部分层次结构，从上到下依次为根域名服务器、顶级域名服务器和权威域名服务器。其实根域名服务器在因特网上有13个，大部分位于北美洲。第二层为顶级域服务器，这些服务器负责顶级域名（如 com、org、net、edu）和所有国家的顶级域名（如uk、fr、ca 和 jp）。在第三层为权威 DNS 服务器，因特网上具有公共可访问主机（例如 Web 服务器和邮件服务器）的每个组织机构必须提供公共可访问的 DNS 记录，这些记录由组织机构的权威 DNS 服务器负责保存，这些记录将这些主机的名称映射为 IP 地址。

除此之外，还有一类重要的 DNS 服务器，叫做本地 DNS 服务器。本地 DNS 服务器严格来说不在 DNS 服务器的层次结构中，但它对 DNS 层次结构是很重要的。一般来说，每个网络服务提供商（ISP） 都有一台本地 DNS 服务器。当主机与某个 ISP 相连时，该 ISP 提供一台主机的 IP 地址，该主机具有一台或多台其本地 DNS 服务器的 IP 地址。主机的本地 DNS 服务器通常和主机距离较近，当主机发起 DNS 请求时，该请求被发送到本地 DNS 服务器，它起着代理的作用，并将该请求转发到 DNS 服务器层次结构中。

我们以一个例子来了解 DNS 的工作原理，假设主机 A（IP 地址为 abc.xyz.edu） 想知道主机 B 的 IP 地址 （def.mn.edu），如下图所示，主机 A 首先向它的本地 DNS 服务器发送一个 DNS 查询报文。该查询报文含有被转换的主机名 def.mn.edu。本地 DNS 服务器将该报文转发到根 DNS 服务器，根 DNS 服务器注意到查询的 IP 地址前缀为 edu 后向本地 DNS 服务器返回负责 edu 的顶级域名服务器的 IP 地址列表。该本地 DNS 服务器则再次向这些 顶级域名服务器发送查询报文。该顶级域名服务器注意到 mn.edu 的前缀，并用权威域名服务器的 IP 地址进行响应。通常情况下，顶级域名服务器并不总是知道每台主机的权威 DNS 服务器的 IP 地址，而只知道中间的某个服务器，该中间 DNS 服务器依次能找到用于相应主机的 IP 地址，我们假设中间经历了权威服务器 ① 和 ②，最后找到了负责 def.mn.edu 的权威 DNS 服务器 ③，之后，本地 DNS 服务器直接向该服务器发送查询报文从而获得主机 B 的IP 地址。

在上图中，IP 地址的查询其实经历了两种查询方式，分别是递归查询和迭代查询。

域名解析查询的两种方式：

递归查询：如果主机所询问的本地域名服务器不知道被查询域名的 IP 地址，那么本地域名服务器就以 DNS 客户端的身份，向其他根域名服务器继续发出查询请求报文，即替主机继续查询，而不是让主机自己进行下一步查询，如上图步骤（1）和（10）。

迭代查询：当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么给出所要查询的 IP 地址，要么告诉本地服务器下一步应该找哪个域名服务器进行查询，然后让本地服务器进行后续的查询，如上图步骤（2）~（9）。

DNS 为什么既使用 TCP 又使用 UDP？

当进行区域传送（主域名服务器向辅助域名服务器传送变化的那部分数据）时会使用 TCP，因为数据同步传送的数据量比一个请求和应答的数据量要多，而 TCP 允许的报文长度更长，因此为了保证数据的正确性，会使用基于可靠连接的 TCP。
当客户端向 DNS 服务器查询域名 ( 域名解析) 的时候，一般返回的内容不会超过 UDP 报文的最大长度，即 512 字节。用 UDP 传输时，不需要经过 TCP 三次握手的过程，从而大大提高了响应速度，但这要求域名解析器和域名服务器都必须自己处理超时和重传从而保证可靠性。

怎么实现 DNS 劫持？

DNS 劫持即域名劫持，是通过将原域名对应的 IP 地址进行替换从而使得用户访问到错误的网站或者使得用户无法正常访问网站的一种攻击方式。域名劫持往往只能在特定的网络范围内进行，范围外的 DNS 服务器能够返回正常的 IP 地址。攻击者可以冒充原域名所属机构，通过电子邮件的方式修改组织机构的域名注册信息，或者将域名转让给其它组织，并将新的域名信息保存在所指定的 DNS 服务器中，从而使得用户无法通过对原域名进行解析来访问目的网址。

具体实施步骤如下：

• 获取要劫持的域名信息：攻击者首先会访问域名查询站点查询要劫持的域名信息。
• 控制域名相应的 E-MAIL 账号：在获取到域名信息后，攻击者通过暴力破解或者专门的方法破解公司注册域名时使用的 E-mail 账号所对应的密码。更高级的攻击者甚至能够直接对 E-mail 进行信息窃取。
• 修改注册信息：当攻击者破解了 E-MAIL 后，会利用相关的更改功能修改该域名的注册信息，包括域名拥有者信息，DNS 服务器信息等。
• 使用 E-MAIL 收发确认函：在修改完注册信息后，攻击者在 E-mail 真正拥有者之前收到修改域名注册信息的相关确认信息，并回复确认修改文件，待网络公司恢复已成功修改信件后，攻击者便成功完成 DNS 劫持。

用户端的一些预防手段：

• 直接通过 IP 地址访问网站，避开 DNS 劫持。
• 由于域名劫持往往只能在特定的网络范围内进行，因此一些高级用户可以通过网络设置让 DNS 指向正常的域名服务器以实现对目的网址的正常访问，例如将计算机首选 DNS 服务器的地址固定为 8.8.8.8。

网络编程

通常网络编程默认是指TCP编程，即用socket（是ip地址与端口的结合协议，是进程间通信的一种方式）函数创建一个socket用于TCP通讯，函数参数通常填为SOCK_STREAM。即socket(PF_INET, SOCK_STREAM, 0)，这表示建立一个socket用于流式网络通讯。SOCK_STREAM这种的特点是面向连接的，即每次收发数据之前必须通过connect建立连接，也是双向的，即任何一方都可以收发数据，协议本身提供了一些保障机制保证它是可靠的、有序的，即每个包按照发送的顺序到达接收方。

而SOCK_DGRAM这种是UDP协议的网络通讯，它是无连接的，不可靠的，因为通讯双方发送数据后不知道对方是否可以正常收到数据。任何一方建立一个socket以后就可以用sendto发送数据，也可以用recvfrom接收数据。根本不关心对方是否存在，是否发送了数据。它的特点是通讯速度比较快。

socket的组成与作用：在网络传输中用于唯一标识两个端点（包括（ip+port））的链接。4个要素：客户端地址、客户端端口、服务器地址、服务器端口。

TCP服务器端编程的一般步骤是：
　　1、创建一个socket，用函数socket()；
　　2、设置socket属性，用函数setsockopt(); * 可选
　　3、绑定IP地址、端口等信息到socket上，用函数bind();
　　4、开启监听，用函数listen()；
　　5、接收客户端上的连接，用函数accept()；
　　6、收发数据，用函数send()和recv()，或者read()和write();
　　7、关闭网络连接；
　　8、关闭监听；
TCP客户端编程的一般步骤是：
　　1、创建一个socket，用函数socket()；
　　2、设置socket属性，用函数setsockopt();* 可选
　　3、绑定IP地址、端口等信息到socket上，用函数bind();* 可选
　　4、设置要连接的服务器的IP地址和端口等属性；
　　5、连接服务器，用函数connect()；
　　6、收发数据，用函数send()和recv()，或者read()和write();
　　7、关闭网络连接；
UDP编程步骤要简单许多，UDP服务器端编程的一般步骤是：
　　1、创建一个socket，用函数socket()；
　　2、设置socket属性，用函数setsockopt();* 可选
　　3、绑定IP地址、端口等信息到socket上，用函数bind();
　　4、循环接收数据，用函数recvfrom();
　　5、关闭网络连接；
UDP客户端编程的一般步骤是：
　　1、创建一个socket，用函数socket()；
　　2、设置socket属性，用函数setsockopt();* 可选
　　3、绑定IP地址、端口等信息到socket上，用函数bind();* 可选
　　4、设置对方的IP地址和端口等属性;
　　5、发送数据，用函数sendto();
　　6、关闭网络连接；

socket() 套接字

套接字（Socket）是对网络中不同主机上的应用进程之间进行双向通信的端点的抽象，网络进程通信的一端就是一个套接字，不同主机上的进程便是通过套接字发送报文来进行通信。例如 TCP 用主机的 IP 地址 + 端口号作为 TCP 连接的端点，这个端点就叫做套接字。

套接字主要有以下三种类型：

• 流套接字（SOCK_STREAM）：流套接字基于 TCP 传输协议，主要用于提供面向连接、可靠的数据传输服务。由于 TCP 协议的特点，使用流套接字进行通信时能够保证数据无差错、无重复传送，并按顺序接收，通信双方不需要在程序中进行相应的处理。
• 数据报套接字（SOCK_DGRAM）：和流套接字不同，数据报套接字基于 UDP 传输协议，对应于无连接的 UDP 服务应用。该服务并不能保证数据传输的可靠性，也无法保证对端能够顺序接收到数据。此外，通信两端不需建立长时间的连接关系，当 UDP 客户端发送一个数据给服务器后，其可以通过同一个套接字给另一个服务器发送数据。当用 UDP 套接字时，丢包等问题需要在程序中进行处理。
• 原始套接字（SOCK_RAW）：由于流套接字和数据报套接字只能读取 TCP 和 UDP 协议的数据，当需要传送非传输层数据包（例如 Ping 命令时用的 ICMP 协议数据包）或者遇到操作系统无法处理的数据包时，此时就需要建立原始套接字来发送。

socket原理

套接字（socket）是通信的基石，是支持TCP/IP协议的网络通信的基本操作单元。它是网络通信过程中端点的抽象表示，包含进行网络通信必须的五种信息：使用的通信协议；本地主机的IP地址；本地进程的协议端口；远地主机的IP地址；远地进程的协议端口。

应用层可以和传输层通过Socket接口，区分来自不同应用程序进程或网络连接的通信，实现数据传输的并发服务。

建立Socket连接：
建立Socket连接至少需要一对套接字，其中一个运行于客户端，称为ClientSocket；另一个运行于服务器端，称为ServerSocket 。套接字之间的连接过程分为三个步骤：服务器监听，客户端请求，连接确认。

• 服务器监听：服务器端套接字并不定位具体的客户端套接字，而是处于等待连接的状态，实时监控网络状态，等待客户端的连接请求。
• 客户端请求：指客户端的套接字发起连接请求，要连接的目标是服务器端的套接字。为此，客户端的套接字必须首先描述它要连接的服务器的套接字，指出服务器端套接字的地址和端口号，然后就向服务器端套接字发起连接请求。
• 连接确认：当服务器端套接字监听或接收到客户端套接字的连接请求时，就响应该请求，建立一个新的线程，把服务器端套接字的描述发给客户端，一旦客户端确认了此描述，双方就正式建立连接。而服务器端套接字继续处于监听状态，继续接收其他客户端套接字的连接请求。

Socket连接与TCP连接：
创建Socket连接时，可以指定使用的传输层协议（支持TCP或UDP），当使用TCP协议进行连接时，该Socket连接就是一个TCP连接。

Socket连接与HTTP连接：
很多情况需要服务器主动向客户端推送数据，保证客户端与服务器数据的实时与同步。此时若双方建立的是Socket连接，服务器可以直接将数据传给客户端；若双方建立的是HTTP连接，则服务器需要等到客户端发送一次请求后才能将数据传回给客户端。因此，客户端定时向服务器端发送连接请求，不仅可以保持在线，还可以“询问”服务器是否有新的数据，如果有就将数据传给客户端。

为什么 fidder，charles 能抓到你的包？【抓取数据包的过程】

假如我们需要抓取客户端的数据包，需要监控客户端与服务器交互之间的网络节点，监控其中任意一个网络节点（网卡），获取所有经过网卡中的数据，对这些数据按照网络协议进行解析，这就是抓包的基本原理。而中间的网络节点不受我们控制，是基本无法实现抓包的，因此只能在客户端与服务器之间进行抓包。

（1）当采用抓包工具抓取 HTTP 数据包时，过程较为简单：

• 首先抓包工具会提出代理服务，客户端需要连接该代理；
• 客户端发出 HTTP 请求时，会经过抓包工具的代理，抓包工具将请求的原文进行展示；
• 抓包工具使用该原文将请求发送给服务器；
• 服务器返回结果给抓包工具，抓包工具将返回结果进行展示；
• 抓包工具将服务器返回的结果原样返回给客户端。
• 这里抓包工具相当于透明人，数据经过的时候它一只手接到数据，然后另一只手把数据传出去。

（2）当抓取 HTTPS 数据包时：

• 客户端连接抓包工具提供的代理服务，并安装抓包工具的根证书；
• 客户端发出 HTTPS 请求，抓包工具模拟服务器与客户端进行 TLS 握手交换密钥等流程；
• 抓包工具发送一个 HTTPS 请求给客户端请求的目标服务器，并与目标服务器进行 TLS 握手交换密钥等流程；
• 客户端使用与抓包工具协定好的密钥加密数据后发送给抓包工具；
• 抓包工具使用与客户端协定好的密钥解密数据，并将结果进行展示；
• 抓包工具将解密后的客户端数据，使用与服务器协定好的密钥进行加密后发送给目标服务器；
• 服务器解密数据后，做对应的逻辑处理，然后将返回结果使用与抓包工具协定好的密钥进行加密发送给抓包工具；
• 抓包工具将服务器返回的结果，用与服务器协定好的密钥解密，并将结果进行展示；
• 抓包工具将解密后的服务器返回数据，使用与客户端协定好的密钥进行加密后发送给客户端；
• 客户端解密数据。

这个时候抓包工具对客户端来说相当于服务器，对服务器来说相当于客户端。在这个传输过程中，客户端会以为它就是目标服务器，服务器也会以为它就是请求发起的客户端。

如果你访问一个网站很慢，怎么排查和解决？

网页打开速度慢的原因有很多，这里列举出一些较常出现的问题：

• 首先最直接的方法是查看本地网络是否正常，可以通过网络测速软件例如电脑管家等对电脑进行测速，若网速正常，我们查看网络带宽是否被占用，例如当你正在下载电影时并且没有限速，是会影响你打开网页的速度的，这种情况往往是处理器内存小导致的；
• 当网速测试正常时，我们对网站服务器速度进行排查，通过 ping 命令查看链接到服务器的时间和丢包等情况，一个速度好的机房，首先丢包率不能超过 1%，其次 ping 值要小，最后是 ping 值要稳定，如最大和最小差值过大说明路由不稳定。或者我们也可以查看同台服务器上其他网站的打开速度，看是否其他网站打开也慢。
• 如果网页打开的速度时快时慢，甚至有时候打不开，有可能是空间不稳定的原因。当确定是该问题时，就要找你的空间商解决或换空间商了，如果购买空间的话，可选择购买购买双线空间或多线空间；如果是在有的地方打开速度快，有的地方打开速度慢，那应该是网络线路的问题。电信线路用户访问放在联通服务器的网站，联通线路用户访问放在电信服务器上的网站，相对来说打开速度肯定是比较慢。
• 从网站本身找原因。

网站的问题主要包括网站程序设计、网页设计结构和网页内容三个部分。

• 网站程序设计：当访问网页中有拖慢网站打开速度的代码，会影响网页的打开速度，例如网页中的统计代码，我们最好将其放在网站的末尾。因此我们需要查看网页程序的设计结构是否合理；
• 网页设计结构：如果是 table 布局的网站，查看是否嵌套次数太多，或是一个大表格分成多个表格这样的网页布局，此时我们可以采用 div 布局并配合 css 进行优化。
• 网页内容：查看网页中是否有许多尺寸大的图片或者尺寸大的 flash 存在，我们可以通过降低图片质量，减小图片尺寸，少用大型 flash 加以解决。此外，有的网页可能过多地引用了其他网站的内容，若某些被引用的网站访问速度慢，或者一些页面已经不存在了，打开的速度也会变慢。一种直接的解决方法是去除不必要的加载项。

其他协议

（1）FTP。FTP（File Transfer Protocol，文件传输协议）是用于在网络上进行文件传输的一套标准协议，使用客户/服务器模式，使用 TCP 数据报，提供交互式访问，双向传输。
TFTP（Trivial File Transfer Protocol，简单文件传输协议）一个小且易实现的文件传输协议，也使用客户/服务器方式，使用 UDP 数据报，只支持文件传输而不支持交互，没有列目录，不能对用户进行身份鉴定。

（2）SMTP。SMTP（Simple Mail Transfer Protocol，简单邮件传输协议）是在 Internet 传输 Email 的标准，是一个相对简单的基于文本的协议。在其之上指定了一条消息的一个或多个接收者（在大多数情况下被确认是存在的），然后消息文本会被传输。可以很简单地通过 Telnet 程序来测试一个 SMTP 服务器。SMTP 使用 TCP 端口 25。

（3）DHCP。DHCP ( Dynamic Host Configuration Protocol，动态主机设置协议 ) 是一个局域网的网络协议，使用 UDP 协议工作，主要有两个用途：
用于内部网络或网络服务供应商自动分配 IP 地址给用户
用于内部网络管理员作为对所有电脑作中央管理的手段

（4）SNMP。SNMP（Simple Network Management Protocol，简单网络管理协议）构成了互联网工程工作小组（IETF，Internet Engineering Task Force）定义的 Internet 协议族的一部分。该协议能够支持网络管理系统，用以监测连接到网络上的设备是否有任何引起管理上关注的情况。

FTP的主动模式和被动模式？连接过程？

文件传输协议（FTP）是网络共享文件的传输协议，在网络应用软件中具有广泛的应用。FTP的目标是提高文件的共享性和可靠高效地传送数据。FTP只通过TCP连接，没有用于FTP的UDP组件。

一般的 客户端/服务器（C/S）结构 应用程序只会建立一个 Socket 连接，这个连接同时处理服务器端和客户端的连接命令和数据传输。而FTP协议将命令与数据分开传送，提高了效率。FTP使用了两个端口, 一个数据端口和一个命令端口(或控制端口)。通常21端口是命令端口，20端口是数据端口。当混入主动/被动模式的概念时，数据端口就有可能不是20了。

FTP协议要用到两个TCP连接，一个是命令连接，用来在FTP客户端与服务器之间传递命令；另一个是数据连接，用来上传或下载数据。无论是主动模式还是被动模式，要进行文件传输都必须依次建立两个连接。

主动模式FTP

服务端通过指定的数据传输端口（默认20），主动连接客户端提交的端口，向客户端发送数据。
主动模式下，FTP客户端随机开启一个非特殊的端口N（N > 1023）连入到FTP服务器的命令端口–21端口。然后客户端在N+1端口监听，并且通过N+1端口发送命令给FTP服务器。服务器接收到命令后，会用其本地的FTP数据端口（通常是20）来连接客户端指定的端口N+1，进行数据传输。

优点：服务端配置简单，利于服务器安全管理，服务器只需要开放21端口。
缺点：如果客户端开启了防火墙，或客户端处于内网（NAT网关之后），那么服务器对客户端端口发起的连接可能会失败。

被动模式FTP

在被动方式FTP中，命令连接和数据连接都由客户端，这样就可以解决从服务器到客户端的数据端口方向的连接被防火墙过滤掉的问题。服务端开启数据传输端口的监听，被动等待客户端的连接，然后向客户端发送数据。
在被动模式下，FTP客户端随机开启一个大于1024的端口N向服务器的21端口发起连接，同时会开启N+1端口。然后向服务器发送PASV命令，通知服务器自己处于被动模式。服务器收到命令后，会开放一个大于1024的端口P进行监听，然后用PORT P命令通知客户端，数据端口是P。客户端收到命令后，会通过N+1号端口连接服务器的端口P，然后在两个端口之间进行数据传输。

优点：对客户端网络环境没有要求。
缺点：服务器配置管理复杂，不利于安全，服务器需要开放随机高位端口以便客户端可以连接，因此大多数FTP服务软件都可以手动配置被动端口的范围。

两种模式的比较

主动模式传送数据是“服务器”连接到“客户端”的端口，对FTP服务器的管理有利，但对客户端的管理不利。被动模式传送数据是“客户端”连接到“服务器”的端口，对FTP客户端的管理有利，但对服务器端的管理不利。
主动模式需要客户端开放端口给服务器，很多客户端都是在防火墙内，开放端口给FTP服务器访问比较困难。被动模式只需要服务器开放端口给客户端连接就行。

FTP的工作流程

FTP 与大多数 Internet 服务一样，使用的也是“客户端/服务器”模式。用户通过一个支持 FTP 协议的客户机程序，连接在远程主机上的 FTP 服务器程序。通过客户端向服务器端发送 FTP 命令，服务器执行该命令，并将执行结果返回给客户端。由于“控制连接”的因素，客户端发送的 FTP 命令，服务器都会有对应的应答。
FTP 进行文件传输的基本工作流程主要分为 4 个阶段，即建立连接阶段、身份认证阶段、命令交互阶段和断开连接阶段。

• 建立连接阶段：该阶段是FTP客户端通过TCP三次握手与FTP服务器端建立连接。客户端向FTP服务器发出建立连接请求，FTP服务器对请求进行应答。如果 FTP 服务器上的 21 端口是启用的，可以接受来自其他主机的请求，给出应答220，表示服务就绪，即告诉客户端需要的FTP服务已经准备好了。返回应答以后，FTP服务器需要客户端进行身份认证，向客户端发送身份认证请求。
• 身份认证阶段：指客户端需要向FTP服务器提供登录所需的用户名和密码。FTP服务器对客户端输入的用户名和密码都会给出相应的应答。如果客户端输入的用户名和密码正确，将成功登录FTP服务器，此时进入FTP会话。
• 命令交互阶段：在FTP会话中，用户可以执行FTP命令进行文件传输，如查看目录信息、上传或下载文件等。客户端输入要执行的FTP命令后，服务器同样会给出应答。如果输入的执行命令正确，服务器会将命令的执行结果返回给客户端。执行结果返回完成后，服务器继续给出应答。
• 断开连接阶段：当客户端不再与FTP服务器进行文件传输时需要断开连接。客户端向FTP服务器发送断开连接请求，服务器收到请求后给出相应的应答。

网页解析全过程【用户输入网址到显示对应页面的全过程】

• DNS 解析：当用户输入一个网址并按下回车键的时候，浏览器获得一个域名，而在实际通信过程中，我们需要的是一个 IP 地址，因此我们需要先把域名转换成相应 IP 地址。【具体细节参看问题 16，17】
• TCP 连接：浏览器通过 DNS 获取到 Web 服务器真正的 IP 地址后，便向 Web 服务器发起 TCP 连接请求，通过 TCP 三次握手建立好连接后，浏览器便可以将 HTTP 请求数据发送给服务器了。【三次握手放在传输层详细讲解】
• 发送 HTTP 请求：浏览器向 Web 服务器发起一个 HTTP 请求，HTTP 协议是建立在 TCP 协议之上的应用层协议，其本质是在建立起的TCP连接中，按照HTTP协议标准发送一个索要网页的请求。在这一过程中，会涉及到负载均衡等操作。
• 处理请求并返回：服务器获取到客户端的 HTTP 请求后，会根据 HTTP 请求中的内容来决定如何获取相应的文件，并将文件发送给浏览器。
• 浏览器渲染：浏览器根据响应开始显示页面，首先解析 HTML 文件构建 DOM 树，然后解析 CSS 文件构建渲染树，等到渲染树构建完成后，浏览器开始布局渲染树并将其绘制到屏幕上。
• 断开连接：客户端和服务器通过四次挥手终止 TCP 连接。

负载均衡

负载均衡，英文名为 Load Balance，其含义是指将负载（工作任务）进行平衡、分摊到多个操作单元上进行运行，例如 FTP 服务器、Web 服务器、企业核心服务器和其他主要任务服务器等，从而协同完成工作任务。负载均衡建立在现有的网络之上，它提供了一种透明且廉价有效的方法扩展服务器和网络设备的带宽、增加吞吐量、加强网络处理能力并提高网络的灵活性和可用性。

负载均衡是分布式系统架构设计中必须考虑的因素之一，例如天猫、京东等大型用户网站中为了处理海量用户发起的请求，其往往采用分布式服务器，并通过引入反向代理等方式将用户请求均匀分发到每个服务器上，而这一过程所实现的就是负载均衡。