[TOC] <details> <summary>一、你知道 DNS 协议嘛？描述一下从输入域名到显示的过程（从 DNS 解析到 HTTP 链接建立到内容返回浏览器渲染）</summary> ``` 1. 浏览器查询 DNS，获取域名对应的IP地址：具体过程包括浏览器搜索自身的DNS缓存、 搜索操作系统的DNS缓存、读取本地的Host文件和向本地DNS服务器进行查询等。对于向 本地DNS服务器进行查询，如果要查询的域名包含在本地配置区域资源中，则返回解析结果 给客户机，完成域名解析(此解析具有权威性)；如果要查询的域名不由本地DNS服务器区域 解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析（此解 析不具有权威性）。如果本地域名服务器并未缓存该网址映射关系，那么将根据其设置发起 递归查询或者迭代查询； 2. 浏览器获得域名对应的IP地址以后，浏览器向服务器请求建立链接，发起三次握手； 3. TCP/IP链接建立起来后，浏览器向服务器发送HTTP请求； 4. 服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理 结果及相应的视图返回给浏览器； 5. 浏览器解析并渲染视图，若遇到对js文件、css文件及图片等静态资源的引用，则重复上 述步骤并向服务器请求这些资源； 6. 浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面。 ``` </details> <br /> <details> <summary>二、递归查询和迭代查询，具体说一说什么样子的？</summary> ``` 1.主机向本地域名服务器的查询一般都是采用递归查询：如果主机所询问的本地域名服务器 不知道被查询的IP地址，那么本地域名服务器就以DNS客户的身份，向其他根域名器继续发 出查询请求报文（即替该主机继续查询），而不是让该主机自己进行下一步查询。因此，递 归查询返回的查询结果或者是所要查询的ip地址，或者是报错，或者无法查询到所需要的IP地址。 2.本地域名服务器向根域名服务器的查询通常是采用迭代查询（iterative query）迭代查询的 特点是这样的：当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么给出 所要查询的IP地址，要么告诉本地域名服务器：“你下一步应当向哪一个域名服务器进行查询”。 然后让本地域名服务器进行后续的查询（而不是替本地域名服务器进行后续的查询）。根域 名服务器通常是把自己知道的顶级域名服务器的IP地址告诉本地域名服务器，让本地域名服务 器再向顶级域名服务器查询。顶级域名服务器在收到本地域名服务器的查询请求后，要么给 出所要查询的IP地址，要么告诉本地域名服务器下一步应当向哪一个权限域名服务器进行查询， 本地域名服务器就这样进行迭代查询。最后，知道了所要解析的域名的IP地址，然后把这个结 果返回给发起查询的主机。当然，本地域名服务器也可以采用递归查询，这取决于最初的查询 请求报文的设置是要求使用哪一种查询方式。 ``` </details> <br /> <details> <summary>三、本地域名服务器向根服务器查询的是什么？</summary> ``` 是要从输入的域名检验根服务器中对应的域名服务器的 IP 地址 ``` </details> <br /> <details> <summary>四、TCP 的三次握手，详细描述一下，最好包括它的一些状态</summary>  ``` 第一次握手：Client将SYN置1，随机产生一个初始序列号seq发送给Server，进入SYN_SENT状态； 第二次握手：Server收到Client的SYN=1之后，知道客户端请求建立连接，将自己的SYN置1，ACK 置1，产生一个ACKnum=Seq number+1，并随机产生一个自己的初始序列号，发送给客户端；进入 SYN_RCVD状态； 第三次握手：客户端检查ACKnum是否为序列号+1，ACK是否为1，检查正确之后将自己的ACK置为1， 产生一个ACKnum=服务器发的序列号+1，发送给服务器；进入ESTABLISHED状态；服务器检查ACK 为1和ACKnum为序列号+1之后，也进入ESTABLISHED状态；完成三次握手，连接建立。 ``` </details> <br /> <details> <summary>五、DNS 用的 TCP 还是 UDP？为什么用 UDP？</summary> ``` 衡量计算机通信快慢的指标是“响应时间”，即从用户发出通信指令（输入网址敲回车键）开始， 到用户看到完整页面为止，所流逝的时间。 响应时间( Response Time) 以浏览器为例,这个响应时间大体分为三部分 响应时间 = DNS域名解析时间 + TCP连接建立时间 + HTTP交易时间 如果让响应时间尽可能小,只有让等号右侧的三者尽可能小。 TCP连接是定的三次握手,所以很难有进一步缩小的空间。 HTTP交易,基于Request / Response,也很难有提升的空间。 所以,只能让DNS域名解析的时间越小越好。 域名解析 釆用TCP传输,则域名解析时间为: DNS域名解析时间 = TCP连接时间 + DNS交易时间 釆用UDP传输,则域名解析时间为: DNS域名解析时间 = DNS交易时间 很显然,采用UDP专输,DNS域名解析时间更小。 DNS在进行区域传输的时候使用TCP协议，其它时候则使用UDP协议；  DNS的规范规定了2种类型的DNS服务器，一个叫主DNS服务器，一个叫辅助DNS服务器。 在一个区中主DNS服务器从自己本机的数据文件中读取该区的DNS数据信息，而辅助 DNS服务器则从区的主DNS服务器中读取该区的DNS数据信息。当一个辅助DNS服务器 启动时，它需要与主DNS服务器通信，并加载数据信息，这就叫做区传送（zone transfer）。  为什么既使用TCP又使用UDP？  首先了解一下TCP与UDP传送字节的长度限制：  UDP报文的最大长度为512字节，而TCP则允许报文长度超过512字节。当DNS查询超过 512字节时，协议的TC标志出现删除标志，这时则使用TCP发送。通常传统的UDP报文 一般不会大于512字节。  区域传送时使用TCP，主要有一下两点考虑：  1.辅域名服务器会定时（一般时3小时）向主域名服务器进行查询以便了解数据是否有 变动。如有变动，则会执行一次区域传送，进行数据同步。区域传送将使用TCP而不是 UDP，因为数据同步传送的数据量比一个请求和应答的数据量要多得多。  2.TCP是一种可靠的连接，保证了数据的准确性。  域名解析时使用UDP协议：  客户端向DNS服务器查询域名，一般返回的内容都不超过512字节，用UDP传输即可。不用 经过TCP三次握手，这样DNS服务器负载更低，响应更快。虽然从理论上说，客户端也可 以指定向DNS服务器查询的时候使用TCP，但事实上，很多DNS服务器进行配置的时候， 仅支持UDP查询包。 ``` </details> <br /> <details> <summary>六、TCP和UDP的区别</summary> ``` 1. TCP是面向连接的，UDP是无连接的； 什么叫无连接？ 面向无连接 UDP 不需要与 TCP一样在发送数据前进行三次握手建立连接，UDP想发数据 就直接发送了；并且UDP只是数据报文的搬运工，不会对数据报文进行任何拆分和拼接操作。 2. TCP是可靠的，UDP不可靠； UDP不可靠 首先不可靠性体现在无连接上，通信都不需要建立连接，想发就发，这样的情况 肯定不可靠的；并且收到什么数据就传递什么数据，也不会备份数据，发送数据也不会关心 对方是否已经正确接收到数据； 再者网络环境时好时坏，但是 UDP 因为没有拥塞控制，一 直会以恒定的速度发送数据；即使网络条件不好，也不会对发送速率进行调整，这样实现 的弊端就是在网络条件不好的情况下可能会导致丢包，但是优点也很明显，在某些实时性要 求高的场景（比如直播、电话会议等）就需要使用 UDP 而不是 TCP； 3. TCP只支持点对点通信，UDP支持一对一、一对多、多对一、多对多； 由于 UDP 不会建立连接，因此它可以给任何人传递数据，不止支持一对一的传输方式，同样 支持一对多、多对多、多对一的方式； 4. TCP是面向字节流的，UDP是面向报文的； UDP是面向报文的 发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付IP层 （UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界）； 面向字节流是指发送数据时以字节为单位，一个数据包可以拆分成若干组进行发送，而UDP 一个报文只能一次发完。 5. TCP有拥塞控制机制，UDP没有。 网络出现的拥塞不会使源主机的发送速率降低，这对某些实时应用是很重要的，比如媒体通信，游戏； 6. TCP首部开销（20字节）比UDP首部开销（8字节）要大 头部开销小，传输数据高效 UDP 的头部开销小，只有八字节，在传输数据报文时是比较高效 的（在某些实时性要求高的场景，例如直播、电话会议、媒体传输等场景经常使用UDP协议）； 7. UDP 的主机不需要维持复杂的连接状态表 ``` </details> <br /> <details> <summary>七、TCP 和 UDP 的各自的应用，举例子</summary> ``` 对某些实时性要求比较高的情况，选择UDP，比如游戏，媒体通信，实时视频流（直播）， 即使出现传输错误也可以容忍；其它大部分情况下，HTTP都是用TCP，因为要求传输的内 容可靠，不出现丢失。 ``` </details> <br /> <details> <summary>八、TCP 的四次挥手</summary>  ``` - 第一次挥手：Client将FIN置为1，发送一个序列号seq给Server；进入FIN_WAIT_1状态； - 第二次挥手：Server收到FIN之后，发送一个ACK=1，ACKnum=收到的序列号+1；进入 CLOSE_WAIT状态。此时客户端已经没有要发送的数据了，但仍可以接受服务器发来的数据。 - 第三次挥手：Server将FIN置1，发送一个序列号给Client；进入LAST_ACK状态； - 第四次挥手：Client收到服务器的FIN后，进入TIME_WAIT状态；接着将ACK置1，发送 一个ACKnum=序列号+1给服务器；服务器收到后，确认ACKnum后，变为CLOSED状态，不再 向客户端发送数据。客户端等待2*MSL（报文段最长寿命）时间后，也进入CLOSED状态。 完成四次挥手。 ``` </details> <br /> <details> <summary>九、2个MSL指的是什么？为什么要 2 个？</summary> ``` 第四次挥手时，客户端发送给服务器的ACK有可能丢失，TIME_WAIT状态就是用来重发可能 丢失的ACK报文。如果Server没有收到ACK，就会重发FIN，如果Client在2*MSL的时间内 收到了FIN，就会重新发送ACK并再次等待2MSL，防止Server没有收到ACK而不断重发FIN。 MSL(Maximum Segment Lifetime)，指一个片段在网络中最大的存活时间，2MSL就是一个 发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client 推断ACK已经被成功接收，则结束TCP连接。 ``` </details> <br /> <details> <summary>十、TCP 的一些拥塞控制算法了解多少？</summary> ``` 拥塞控制主要由四个算法组成：慢启动（Slow Start）、拥塞避免（Congestion voidance）、 快重传 （Fast Retransmit）、快恢复（Fast Recovery） 1. 慢启动：刚开始发送数据时，先把拥塞窗口（congestion window）设置为一个最大报文段 MSS的数值，每收到一个新的确认报文之后，就把拥塞窗口加1个MSS。这样每经过一个传输轮 次（或者说是每经过一个往返时间RTT），拥塞窗口的大小就会加倍 * 2. 拥塞避免：当拥塞窗口的大小达到慢开始门限(slow start threshold)时，开始执行拥塞避免 算法，拥塞窗口大小不再指数增加，而是线性增加，即每经过一个传输轮次只增加1MSS. > 无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到 确认），就要把慢开始门限ssthresh设置为出现拥塞时的发送方窗口值的一半（但不能小于2）。 然后把拥塞窗口cwnd重新设置为1，执行慢开始算法。（这是不使用快重传的情况） 3. 快重传：快重传要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。 4. 快恢复：当发送方连续收到三个重复确认时，就把慢开始门限减半，然后执行拥塞避免算法。不执行慢开始算法的原因：因为如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方认为现在网络可能没有出现拥塞。 也有的快重传是把开始时的拥塞窗口cwnd值再增大一点，即等于 ssthresh + 3*MSS 。这样做的理由是：既然发送方收到三个重复的确认，就表明有三个分组已经离开了网络。这三个分组不再消耗网络的资源而是停留在接收方的缓存中。可见现在网络中减少了三个分组。因此可以适当把拥塞窗口扩大些。 ``` </details> <br /> <details> <summary>十一、HTTP请求方式 （http有哪些请求方法？）</summary> ``` 1.GET GET请求会显示请求指定的资源。一般来说GET方法应该只用于数据的读取，而不应当用于会产生副作用的 非幂等的操作中。它期望的应该是而且应该是安全的和幂等的。这里的安全指的是，请求不会影响到资源 的状态。 2.HEAD HEAD方法与GET方法一样，都是向服务器发出指定资源的请求。但是，服务器在响应HEAD请求时不会回传 资源的内容部分，即：响应主体。这样，我们可以不传输全部内容的情况下，就可以获取服务器的响应头 信息。HEAD方法常被用于客户端查看服务器的性能。 3.POST POST请求会 向指定资源提交数据，请求服务器进行处理，如：表单数据提交、文件上传等，请求数据会 被包含在请求体中。POST方法是非幂等的方法，因为这个请求可能会创建新的资源或/和修改现有资源。 4.PUT PUT请求会身向指定资源位置上传其最新内容，PUT方法是幂等的方法。通过该方法客户端可以将指定资源 的最新数据传送给服务器取代指定的资源的内容。 5.DELETE DELETE请求用于请求服务器删除所请求URI（统一资源标识符，Uniform Resource Identifier）所标识的 资源。DELETE请求后指定资源会被删除，DELETE方法也是幂等的。 6.CONNECT CONNECT方法是HTTP/1.1协议预留的，能够将连接改为管道方式的代理服务器。通常用于SSL加密服务器的 链接与非加密的HTTP代理服务器的通信。 7.OPTIONS OPTIONS请求与HEAD类似，一般也是用于客户端查看服务器的性能。 这个方法会请求服务器返回该资源所 支持的所有HTTP请求方法，该方法会用'\*'来代替资源名称，向服务器发送OPTIONS请求，可以测试服务器 功能是否正常。JavaScript的XMLHttpRequest对象进行CORS跨域资源共享时，就是使用OPTIONS方法发送 嗅探请求，以判断是否有对指定资源的访问权限。 8.TRACE TRACE请求服务器回显其收到的请求信息，该方法主要用于HTTP请求的测试或诊断。 9.PATCH PATCH方法出现的较晚，它在2010年的RFC 5789标准中被定义。PATCH请求与PUT请求类似，同样用于资源 的更新。 二者有以下两点不同： 1.PATCH一般用于资源的部分更新，而PUT一般用于资源的整体更新。 2.当资源不存在时，PATCH会创建一个新的资源，而PUT只会对已在资源进行更新。 ``` </details> <br /> <details> <summary>十二、POST与PUT区别</summary> ``` 1、PUT请求是向服务器端发送数据的，从而改变信息，该请求就像数据库的update操作一样，用来修改 数据的内容，但是不会增加数据的种类等，也就是说无论进行多少次PUT操作，其结果并没有不同。 2、POST请求同PUT请求类似，都是向服务器端发送数据的，但是该请求会改变数据的种类等资源，就像 数据库的insert操作一样，会创建新的内容。几乎目前所有的提交操作都是用POST请求的。 ``` </details> <br /> <details> <summary>十三、POST长度有限制吗 </summary> asdsadasd </details> <br /> <details> <summary>十四、HTTP常见状态码</summary> ``` 200 OK 最常见的就是成功响应状态码200了， 这表明该请求被成功地完成，所请求的资源发送回客户端。 302 Found 重定向，新的URL会在response 中的Location中返回，浏览器将会自动使用新的URL发出新的Request。 304 Not Modified 代表上次的文档已经被缓存了， 还可以继续使用。 400 Bad Request  客户端请求与语法错误，不能被服务器所理解。 403 Forbidden 服务器收到请求，但是拒绝提供服务 404 Not Found 请求资源不存在（输错了URL） 500 Internal Server Error 服务器发生了不可预期的错误 503 Server Unavailable 服务器当前不能处理客户端的请求，一段时间后可能恢复正常。 ``` </details> <br /> <details> <summary>十五、HTTP请求中Content-Type</summary> ``` 1. Content-Type MediaType，即是Internet Media Type，互联网媒体类型；也叫做MIME类型，在Http协议消息头中， 使用Content-Type来表示具体请求中的媒体类型信息。 例如： Content-Type: text/html;charset:utf-8; 常见的媒体格式类型如下： text/html ： HTML格式 text/plain ：纯文本格式 text/xml ： XML格式 image/gif ：gif图片格式 image/jpeg ：jpg图片格式 image/png：png图片格式 以application开头的媒体格式类型： application/xhtml+xml ：XHTML格式 application/xml ： XML数据格式 application/atom+xml ：Atom XML聚合格式 application/json ： JSON数据格式 application/pdf ：pdf格式 application/msword ： Word文档格式 application/octet-stream ： 二进制流数据（如常见的文件下载） application/x-www-form-urlencoded ： <form encType=””>中默认的encType， form表单数据被编码为key/value格式发送到服务器（表单默认的提交数据的格式） 另外一种常见的媒体格式是上传文件之时使用的： multipart/form-data ： 需要在表单中进行文件上传时，就需要使用该格式 以上就是我们在日常的开发中，经常会用到的若干content-type的内容格式。 通常你选择raw，json类型浏览器或者postman会自动给你在请求中加上这些信息content-type类型 （json属于raw类型） ``` </details> <br /> <details> <summary>十六、https加密是怎么实现（ca证书作用是什么 ）</summary> ``` HTTPS = HTTP + SSL / TLS HTTPS 的整个通信过程可以分为两大阶段：证书验证和数据传输阶段，数据传输阶段又可以分为 非对称加密和对称加密两个阶段。具体流程按图中的序号讲解。 1.客户端请求 HTTPS 网址，然后连接到 server 的 443 端口 (HTTPS 默认端口，类似于 HTTP 的80端口)。 2.采用 HTTPS 协议的服务器必须要有一套数字 CA (Certification Authority)证书，证书是需要 申请的，并由专门的数字证书认证机构(CA)通过非常严格的审核之后颁发的电子证书 (当然了是 要钱的，安全级别越高价格越贵)。颁发证书的同时会产生一个私钥和公钥。私钥由服务端自己保存， 不可泄漏。公钥则是附带在证书的信息中，可以公开的。证书本身也附带一个证书电子签名，这个 签名用来验证证书的完整性和真实性，可以防止证书被篡改。 3.服务器响应客户端请求，将证书传递给客户端，证书包含公钥和大量其他信息，比如证书颁发机构 信息，公司信息和证书有效期等。Chrome 浏览器点击地址栏的锁标志再点击证书就可以看到证书详 细信息。 4.客户端解析证书并对其进行验证。如果证书不是可信机构颁布，或者证书中的域名与实际域名不一 致，或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。 如果证书没有问题，客户端就会从服务器证书中取出服务器的公钥A。然后客户端还会生成一个随机码 KEY，并使用公钥A将其加密。 5.客户端把加密后的随机码 KEY 发送给服务器，作为后面对称加密的密钥。 6.服务器在收到随机码 KEY 之后会使用私钥B将其解密。经过以上这些步骤，客户端和服务器终于建立 了安全连接，完美解决了对称加密的密钥泄露问题，接下来就可以用对称加密愉快地进行通信了。 7.服务器使用密钥 (随机码 KEY)对数据进行对称加密并发送给客户端，客户端使用相同的密钥 (随机码 KEY)解密数据。 8.双方使用对称加密愉快地传输所有数据。 ``` </details> <br /> <details> <summary>十七、tcp拥塞，怎么避免拥塞</summary> ``` 发送方维持一个叫做拥塞窗口cwnd（congestion window）的状态变量。 拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让 自己的发送窗口等于拥塞窗口，另外考虑到接受方的接收能力，发送窗口 可能小于拥塞窗口。慢开始算法的思路就是，不要一开始就发送大量的数据， 先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小。 过程cwnd的大小呈指数增长，直到超过慢启动门限，然后进入拥塞避免阶段， cwnd的大小线性增长，当出现网络拥塞(三个重复的ack或者超时)时候， 将慢启动门限设置为出现拥塞时候大小的一半，cwnd的大小重新从0开始进入 慢启动阶段。 快重传和快恢复：快重传要求接收方在收到一个失序的报文段后就立即发出 重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己 发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就 应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。 ``` </details> <br /> <details> <summary>十八、tcp如何进行流量控制的 </summary> asdsadasd </details> <br /> <details> <summary>十九、浏览器输入`www.baidu.com`后发生了什么？</summary> ``` 1、首先，在浏览器地址栏中输入url，先解析url，检测url地址是否合法 2、浏览器先查看浏览器缓存-系统缓存-路由器缓存，如果缓存中有，会直接在屏幕中显示页面内容。若没有，则跳到第三步操作。 浏览器缓存：浏览器会记录DNS一段时间，因此，只是第一个地方解析DNS请求； 操作系统缓存：如果在浏览器缓存中不包含这个记录，则会使系统调用操作系统，获取操作系统的记录(保存最近的DNS查询缓存)； 路由器缓存：如果上述两个步骤均不能成功获取DNS记录，继续搜索路由器缓存； ISP缓存：若上述均失败，继续向ISP搜索。 3、在发送http请求前，需要域名解析(DNS解析)，解析获取相应的IP地址。 4、浏览器向服务器发起tcp连接，与浏览器建立tcp三次握手。 5、握手成功后，浏览器向服务器发送http请求，请求数据包。 6、服务器处理收到的请求，将数据返回至浏览器 7、浏览器收到HTTP响应 8、浏览器解码响应，如果响应可以缓存，则存入缓存。 9、浏览器发送请求获取嵌入在HTML中的资源（html，css，javascript，图片，音乐······），对于未知类型，会弹出对话框。 10、浏览器发送异步请求。 11、页面全部渲染结束 ``` </details> <br /> <details> <summary>二十、网络传输过程涉及哪些协议</summary> ``` 涉及到的协议： (1) 应用层：HTTP(WWW访问协议)，DNS(域名解析服务) (2) 传输层：TCP(为HTTP提供可靠的数据传输)，UDP(DNS使用UDP传输) (3) 网络层：IP(IP数据数据包传输和路由选择)，ICMP(提供网络传输过程中的差错检测)， ARP(将本机的默认网关IP地址映射成物理MAC地址) ``` </details> <br /> <details> <summary>二十一、tcp,http位于哪层</summary> ``` OSI的7层从上到下分别是 7 应用层(TELNET，HTTP，FTP，NFS，SMTP) 6 表示层 5 会话层 4 传输层 （TCP，UDP） 3 网络层 （IP) 2 数据链路层 1 物理层 ``` </details> <br /> <details> <summary>二十二、说一下cookie 和 session</summary> ``` 1. 由于HTTP协议是无状态的协议，所以服务端需要记录用户的状态时，就需要用某种机制来识具体的用户， 这个机制就是Session.典型的场景比如购物车，当你点击下单按钮时，由于HTTP协议无状态，所以并不知 道是哪个用户操作的，所以服务端要为特定的用户创建了特定的Session，用用于标识这个用户，并且跟踪 用户，这样才知道购物车里面有几本书。这个Session是保存在服务端的，有一个唯一标识。在服务端保存 Session的方法很多，内存、数据库、文件都有。集群的时候也要考虑Session的转移，在大型的网站， 一般会有专门的Session服务器集群，用来保存用户会话，这个时候 Session 信息都是放在内存的，使用 一些缓存服务比如Memcached之类的来放 Session。 2. 思考一下服务端如何识别特定的客户？这个时候Cookie就登场了。每次HTTP请求的时候，客户端都会发送 相应的Cookie信息到服务端。实际上大多数的应用都是用 Cookie 来实现Session跟踪的，第一次创建Session 的时候，服务端会在HTTP协议中告诉客户端，需要在 Cookie 里面记录一个Session ID，以后每次请求把这个 会话ID发送到服务器，我就知道你是谁了。有人问，如果客户端的浏览器禁用了 Cookie 怎么办？一般这种情况 下，会使用一种叫做URL重写的技术来进行会话跟踪，即每次HTTP交互，URL后面都会被附加上一个诸如sid=xxxxx 这样的参数，服务端据此来识别用户。 3. Cookie其实还可以用在一些方便用户的场景下，设想你某次登陆过一个网站，下次登录的时候不想再次输入 账号了，怎么办？这个信息可以写到Cookie里面，访问网站的时候，网站页面的脚本可以读取这个信息，就自动 帮你把用户名给填了，能够方便一下用户。这也是Cookie名称的由来，给用户的一点甜头。 所以，总结一下： Session是在服务端保存的一个数据结构，用来跟踪用户的状态，这个数据可以保存在集群、数据库、文件中； Cookie是客户端保存用户信息的一种机制，用来记录用户的一些信息，也是实现Session的一种方式。 ``` </details> <br /> <details> <summary>二十三、TCP连接细节问题深挖，服务端突然崩溃后客户端接下来的活动过程进行描述，客户端会做什么以及原因。服务器又恢复正常后客户端接下来又会做什么以及原因</summary> asdsadasd </details> <br /> <details> <summary>二十四、网络协议分层介绍</summary> asdsadasd </details> <br /> <details> <summary>二十五、怎么样让UDP可靠</summary> asdsadasd </details> <br /> <details> <summary>二十六、http 协议各个版本的区别？演进的逻辑？ </summary> asdsadasd </details> <br /> <details> <summary>二十七、怎么确定数据包丢了？（冗余 ack）ACK 会不会丢掉呢？</summary> asdsadasd </details> <br /> <details> <summary>二十八、HTTP和HTTPS的区别，HTTP1.0、1.1和2的版本区别，HTTPS的请求过程</summary> asdsadasd </details> <br /> <details> <summary>二十九、滑动窗口机制 </summary> asdsadasd </details> <br /> <details> <summary>三十、DNS劫持</summary> asdsadasd </details> <br /> <details> <summary>三十一、HTTP是基于TCP还是UDP，为什么？</summary> asdsadasd </details> <br />