含泪整理 计算机网络详细八股文（第一部分）

OSI 的七层模型分别是？各自的功能是什么？

简要概括

• 物理层：底层数据传输，如网线；网卡标准。
• 数据链路层：定义数据的基本格式，如何传输，如何标识；如网卡MAC地址。
• 网络层：定义IP编址，定义路由功能；如不同设备的数据转发。
• 传输层：端到端传输数据的基本功能；如 TCP、UDP。
• 会话层：控制应用程序之间会话能力；如不同软件数据分发给不同软件。
• 表示层：数据格式标识，基本压缩加密功能。
• 应用层：各种应用软件，包括 Web 应用。

状态码

状态码详解

100 继续发送（两次post发完头返回100继续发）
200 成功 
204 No Content 
206 Partial Content
301 永久性重定向，url已变更 
302临时重定向 希望用户（本次）能使用新的 URI 访问
304 Not Modified 表示客户端发送附带条件的请求时，服务器端允许请求访问资源，但未满足条件的情况
400 Bad Request客户端请求错误（请求报文中存在语法错误）
401 未授权 当浏览器初次接收到 
401 响应，会弹出认证用的对话窗口 
403 Forbidden权限不足 
404未找到 
500 内部错误
502 Bad Gateway 网关无响应 从上游服务器接收到无效的响应
503 Service Unavailable 该状态码表明服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。
504 Gateway Time-out 未从上游服务器接收到无效的响应

说一下一次完整的HTTP请求过程包括哪些内容

1. 浏览器进行DNS域名解析，得到对应的IP地址
2. 根据这个IP，找到对应的服务器建立连接（三次握手）
3. 建立TCP连接后发起HTTP请求（一个完整的http请求报文）
4. 服务器响应HTTP请求，浏览器得到html代码（服务器如何响应）
5. 浏览器解析html代码，并请求html代码中的资源（如js、css、图片等）
6. 浏览器对页面进行渲染呈现给用户
7. 服务器关闭TCP连接（四次挥手）

DNS是什么？

官方解释：DNS（Domain Name System，域名系统），因特网上作为域名和IP地址相互映射的一个分布式数据库，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。
通过主机名，最终得到该主机名对应的IP地址的过程叫做域名解析（或主机名解析）。
通俗的讲，我们更习惯于记住一个网站的名字，比如www.baidu.com,而不是记住它的ip地址，比如：167.23.10.2。

DNS的工作原理

为了提高 DNS 的解析性能，很多网络都会就近部署 DNS 缓存服务器。于是，就有了以下的 DNS 解析流程。

1. 电脑先查询自身的本地DNS缓存，若未查到接着向下查询。
2. 电脑客户端会发出一个 DNS 请求，问 www.baidu.com 的 IP 是啥啊，并发给本地域名服务器 (本地DNS)。那本地域名服务器 (本地 DNS) 是什么呢？如果是通过 DHCP 配置，本地 DNS 由你的网络服务商（ISP），如电信、移动等自动分配，它通常就在你网络服务商的某个机房。
3. 本地 DNS 收到来自客户端的请求。你可以想象这台服务器上缓存了一张域名与之对应 IP 地址的大表格。如果能找到 www.baidu.com，它直接就返回 IP 地址。如果没有，本地 DNS 会去问它的根域名服务器。根域名服务器是最高层次的，全球共有 13 套。它不直接用于域名解析，但能指明一条道路。
4. 根 DNS 收到来自本地 DNS 的请求，发现后缀是 .com，说：“哦， www.baidu.com 啊，这个域名是由.com 区域管理，我给你它的顶级域名服务器的地址，你去问问它吧。”
5. 本地 DNS 转向问顶级域名服务器：“老二，你能告诉我 www.baidu.com 的 IP 地址吗？”顶级域名服务器就是大名鼎鼎的比如 .com、.net、 .org 这些一级域名，它负责管理二级域名，比如baidu.com，所以它能提供一条更清晰的方向。
6. 顶级域名服务器会给你负责 www.baidu.com 区域的权威 DNS 服务器的地址，让你去那里问。
7. 本地 DNS 转向问权威 DNS 服务器：“您好， www.baidu.com 对应的 IP 是啥呀？”baidu.com 的权威 DNS 服务器，它是域名解析结果的原出处。为啥叫权威呢？就是我的域名我做主。
8. 权威 DNS 服务器查询后将对应的 IP 地址 X.X.X.X 告诉本地 DNS。
9. 本地 DNS 再将 IP 地址返回客户端，客户端和目标建立连接。

为什么域名解析用UDP协议

因为UDP快啊！UDP的DNS协议只要一个请求、一个应答就好了。
而使用基于TCP的DNS协议要三次握手、发送数据以及应答、四次挥手，但是UDP协议传输内容不能超过512字节。
不过客户端向DNS服务器查询域名，一般返回的内容都不超过512字节，用UDP传输即可。

为什么区域传送用TCP协议

• TCP协议可靠性好
• 从主DNS上复制内容啊，你用不可靠的UDP？ 因为TCP协议传输的内容大啊，你用最大只能传512字节的UDP协议？万一同步的数据大于512字节，你怎么办？所以用TCP协议比较好！

DNS负载均衡是什么策略？

当一个网站有足够多的用户的时候，假如每次请求的资源都位于同一台机器上面，那么这台机器随时可能会崩掉。
处理办法就是用DNS负载均衡技术，它的原理是在DNS服务器中为同一个主机名配置多个IP地址,在应答DNS查询时,DNS服务器对每个查询将以DNS文件中主机记录的IP地址按顺序返回不同的解析结果,将客户端的访问引导到不同的机器上去,使得不同的客户端访问不同的服务器,从而达到负载均衡的目的｡例如可以根据每台机器的负载量，该机器离用户地理位置的距离等等。

DNS查询方式有哪些

递归解析(由你去询问的服务器帮你查)

当局部DNS服务器自己不能回答客户机的DNS查询时，它就需要向其他DNS服务器进行查询。此时有两种方式。局部DNS服务器自己负责向其他DNS服务器进行查询，一般是先向该域名的根域服务器查询，再由根域名服务器一级级向下查询。最后得到的查询结果返回给局部DNS服务器，再由局部DNS服务器返回给客户端。

迭代解析（你询问的服务器返回另一个服务器地址你自己去查）

当局部DNS服务器自己不能回答客户机的DNS查询时，也可以通过迭代查询的方式进行解析。局部DNS服务器不是自己向其他DNS服务器进行查询，而是把能解析该域名的其他DNS服务器的IP地址返回给客户端DNS程序，客户端DNS程序再继续向这些DNS服务器进行查询，直到得到查询结果为止。也就是说，迭代解析只是帮你找到相关的服务器而已，而不会帮你去查。比如说：baidu.com的服务器ip地址在192.168.4.5这里，你自己去查吧，本人比较忙，只能帮你到这里了。

HTTP长连接和短连接的区别

• 在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。
• 而从HTTP/1.1起，默认使用长连接，用以保持连接特性。

什么是TCP粘包/拆包？发生的原因？

由于TCP传输协议是面向字节流的传输协议，没有消息保护边界，所以发送方发送的多个数据包，接收方应用层不知如何区分，可能会被当成一个包来处理，这就是粘包；或者，发送方将一个打包分成多个小包发送，而接收方将它们当成多个包进行处理，这就是拆包。

粘包发生的原因

1. 应用层可能并不会立即读取缓冲区中的数据，或者来不及读取，此时就会造成多个数据包同时在缓冲区中。因为没有划定边界，所以应用层也无法将它们拆分开来，而是一同读取，这就会造成粘包，发送端也类似
2. Nagle算法

拆包现象发生的原因

1. 每个报文能够承载的数据是有限的，会将一个大的数据包分为多个小段，为每个段加上首部后逐一发送，而这就造成了拆包
2. TCP滑动窗口

如果当前要发送的数据包的长度，大于窗口中的剩余空间，那这个数据包就会被拆分，先发送一部分，这样也就造成了拆包。

解决方案

1. 定长协议

定长协议，顾名思义，就是应用层需要发送的每份数据，长度都是固定的。比如说，将数据长度定义为1024字节，所有不满足1024字节的数据，可以通过补0进行填充。而接收方每次读取1024字节，就可以正确区分每一份数据。

• 发送方：每次发送固定长度的数据，若数据长度不够，就使用其他字符填充；
• 接收方：每次读取固定字节的数据；

2. 特殊字符分割 : 我们可以为每一份数据，添加起始字符和结束字符，这样就可以区分了。例如，FTP协议；
3. 变长协议。

这种实现也是比较简单的，对于应用层的报文，可以将它分为报文头部以及报文体，而我们可以在报文头中指定当前报文中数据的长度，这样，接收方就能根据长度，正确地拆分多个粘在一起的数据了。

• 发送方：将发送的报文分为头部和实体，在头部中指明实体中数据的长度；
• 接收方：根据报文头部中的信息，正确地区分多个数据；

大部分应用层协议应该使用的都是这种方式，比如说HTTP协议，HTTP报文分为头部（header）以及实体（body），在HTTP协议的首部中，有一个Content-Length首部行，就是指明body中携带数据的字节数。

4. 通过自定义协议进行粘包和拆包的处理。

为什么服务器会缓存这一项功能?如何实现的

原因

• 缓解服务器压力；
• 降低客户端获取资源的延迟：缓存通常位于内存中，读取缓存的速度更快。并且缓存服务器在地理位置上也有可能比源服务器来得近，例如浏览器缓存。

实现方法

• 让代理服务器进行缓存；
• 让客户端浏览器进行缓存。

HTTP请求方法

客户端发送的 请求报文 第一行为请求行，包含了方法字段。
根据 HTTP 标准，HTTP 请求可以使用多种请求方法。
HTTP1.0 定义了三种请求方法： GET, POST 和 HEAD方法。
HTTP1.1 新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。

序 号	方法	描述
1	GET	请求指定的页面信息，并返回实体主体。
2	HEAD	类似于 GET 请求，只不过返回的响应中没有具体的内容，用于获取报头
3	POST	向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。
4	PUT	从客户端向服务器传送的数据取代指定的文档的内容。
5	DELETE	请求服务器删除指定的页面。
6	CONNECT	HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。
7	OPTIONS	允许客户端查看服务器的性能。
8	TRACE	回显服务器收到的请求，主要用于测试或诊断。
9	PATCH	是对 PUT 方法的补充，用来对已知资源进行局部更新 。

GET 和 POST 的区别，你知道哪些？

1. get是获取数据，post是修改数据
2. get把请求的数据放在url上， 以?分割URL和传输数据，参数之间以&相连，所以get不太安全。而post把数据放在HTTP的包体内（requrest body）
3. get提交的数据最大是2k（ 限制实际上取决于浏览器）， post理论上没有限制。
4. GET产生一个TCP数据包，浏览器会把http header和data一并发送出去，服务器响应200(返回数据); POST产生两个TCP数据包，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok(返回数据)。
5. GET请求会被浏览器主动缓存，而POST不会，除非手动设置。
6. 本质区别：GET是幂等的，而POST不是幂等的

这里的幂等性：幂等性是指一次和多次请求某一个资源具有同样的副作用。简单来说意味着对同一URL的多个请求应该返回同样的结果。

正因为它们有这样的区别，所以不应该且不能用get请求做数据的增删改这些有副作用的操作。因为get请求是幂等的，在网络不好的隧道中会尝试重试。如果用get请求增数据，会有重复操作的风险，而这种重复操作可能会导致副作用（浏览器和操作系统并不知道你会用get请求去做增操作）。

一个TCP连接可以对应几个HTTP请求

在 HTTP/1.0 中，一个服务器在发送完一个 HTTP 响应后，会断开 TCP 链接。
但是这样每次请求都会重新建立和断开 TCP 连接，代价过大。
所以虽然标准中没有设定，某些服务器对 Connection: keep-alive 的 Header 进行了支持。
意思是说，完成这个 HTTP 请求之后，不要断开 HTTP 请求使用的 TCP 连接。这样的好处是连接可以被重新使用，之后发送 HTTP 请求的时候不需要重新建立 TCP 连接，以及如果维持连接，那么 SSL 的开销也可以避免.
故：
如果维持连接，一个 TCP 连接是可以发送多个 HTTP 请求的。

一个 TCP 连接中 HTTP 请求发送可以一起发送么（比如一起发三个请求，再三个响应一起接收）？

HTTP/1.1 存在一个问题，单个 TCP 连接在同一时刻只能处理一个请求，意思是说：两个请求的生命周期不能重叠，任意两个 HTTP 请求从开始到结束的时间在同一个 TCP 连接里不能重叠。
在 HTTP/1.1 存在 Pipelining 技术可以完成这个多个请求同时发送，但是由于浏览器默认关闭，所以可以认为这是不可行的。在 HTTP2 中由于 Multiplexing 特点的存在，多个 HTTP 请求可以在同一个 TCP 连接中并行进行。
那么在 HTTP/1.1 时代，浏览器是如何提高页面加载效率的呢？主要有下面两点：

• 维持和服务器已经建立的 TCP 连接，在同一连接上顺序处理多个请求。
• 和服务器建立多个 TCP 连接。

浏览器对同一 Host 建立 TCP 连接到的数量有没有限制？

假设我们还处在 HTTP/1.1 时代，那个时候没有多路传输，当浏览器拿到一个有几十张图片的网页该怎么办呢？肯定不能只开一个 TCP 连接顺序下载，那样用户肯定等的很难受，但是如果每个图片都开一个 TCP 连接发 HTTP 请求，那电脑或者服务器都可能受不了，要是有 1000 张图片的话总不能开 1000 个TCP 连接吧，你的电脑同意 NAT 也不一定会同意。
有。Chrome 最多允许对同一个 Host 建立六个 TCP 连接。不同的浏览器有一些区别。

如果图片都是 HTTPS 连接并且在同一个域名下，那么浏览器在 SSL 握手之后会和服务器商量能不能用 HTTP2，如果能的话就使用 Multiplexing 功能在这个连接上进行多路传输。不过也未必会所有挂在这个域名的资源都会使用一个 TCP 连接去获取，但是可以确定的是 Multiplexing 很可能会被用到。

如果发现用不了 HTTP2 呢？或者用不了 HTTPS（现实中的 HTTP2 都是在 HTTPS 上实现的，所以也就是只能使用 HTTP/1.1）。
那浏览器就会在一个 HOST 上建立多个 TCP 连接，连接数量的最大限制取决于浏览器设置，这些连接会在空闲的时候被浏览器用来发送新的请求，如果所有的连接都正在发送请求呢？那其他的请求就只能等等了。

什么是HTTPS

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

关键点 HTTPS是什么
回答逻辑

1. 先讲HTTP和HTTPS是哪层协议是干什么的。应用层，超文本传输协议，负责客户端和服务端的连接建立
2. 然后讲HTTPS如何保证传输安全。保证公钥来自服务端
3. 如何保证？通过数字证书和数字签名
4. 什么是数字证书和数字签名。CA用私钥对服务器传来的信息和公钥进行数字签名生成数字证书
5. 拓展讲下SSL协议。SSL协议就基于上述，先通过证书拿公钥，再通过非对称加密传递随机数，后续的数据就基于该随机数对称加密传输

拓展问题

• HTTP和HTTPS有什么区别？https就是http和TCP之间有一层SSL层协议

什么是SSL/TLS ？

SSL代表安全套接字层。它是一种用于加密和验证应用程序（如浏览器）和Web服务器之间发送的数据的协议。 身份验证 ， 加密Https的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制。
SSL/TLS协议作用：认证用户和服务，加密数据，维护数据的完整性的应用层协议加密和解密需要两个不同的密钥，故被称为非对称加密；加密和解密都使用同一个密钥的
对称加密：优点在于加密、解密效率通常比较高 ，HTTPS 在内容传输的加密上使用的是对称加密，非对称加密只作用在证书验证阶段

HTTPS和HTTP的区别

1、HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全， HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全。
2、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。 3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

HTTPS是如何保证数据传输的安全，整体的流程是什么？

HTTPS 在内容传输的加密上使用的是对称加密，非对称加密只作用在证书验证阶段

• 加密分对称加密和非对称加密。对称加密效率高，但是解决不了密钥传输问题；非对称加密可以解决这个问题，但是效率不高。
• 非对称加密需要通过证书和权威机构来验证公钥的合法性。
• HTTPS 是综合了对称加密和非对称加密算法的 HTTP 协议。既保证传输安全，也保证传输效率。

HTTP请求和响应报文有哪些主要字段

请求报文

• 请求行：Request Line
• 请求头：Request Headers
• 请求体：Request Body

响应报文

• 状态行：Status Line
• 响应头：Response Headers
• 响应体：Response Body

Cookie是什么

HTTP 协议是无状态的，主要是为了让 HTTP 协议尽可能简单，使得它能够处理大量事务，HTTP/1.1 引入 Cookie 来保存状态信息。
Cookie 是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器之后向同一服务器再次发起请求时被携带上，用于告知服务端两个请求是否来自同一浏览器。由于之后每次请求都会需要携带 Cookie 数据，因此会带来额外的性能开销（尤其是在移动环境下）。
Cookie 曾一度用于客户端数据的存储，因为当时并没有其它合适的存储办法而作为唯一的存储手段，但现在随着现代浏览器开始支持各种各样的存储方式，Cookie 渐渐被淘汰。
新的浏览器 API 已经允许开发者直接将数据存储到本地，如使用 Web storage API（本地存储和会话存储）或 IndexedDB。

Cookie有什么用途？

• 会话状态管理（如用户登录状态、购物车、游戏分数或其它需要记录的信息）
• 个性化设置（如用户自定义设置、主题等）
• 浏览器行为跟踪（如跟踪分析用户行为等）

Session知识大总结

除了可以将用户信息通过 Cookie 存储在用户浏览器中，也可以利用 Session 存储在服务器端，存储在服务器端的信息更加安全。
Session 可以存储在服务器上的文件、数据库或者内存中。也可以将 Session 存储在 Redis 这种内存型数据库中，效率会更高。

Session 的工作原理是什么

使用 Session 维护用户登录状态的过程如下：

1. 用户进行登录时，用户提交包含用户名和密码的表单，放入 HTTP 请求报文中；
2. 服务器验证该用户名和密码，如果正确则把用户信息存储到 Redis 中，它在 Redis 中的 Key 称为 Session ID；
3. 服务器返回的响应报文的 Set-Cookie 首部字段包含了这个 Session ID，客户端收到响应报文之后将该 Cookie 值存入浏览器中；
4. 客户端之后对同一个服务器进行请求时会包含该 Cookie 值，服务器收到之后提取出 Session ID，从 Redis 中取出用户信息，继续之前的业务操作。

注意：Session ID 的安全性问题，不能让它被恶意攻击者轻易获取，那么就不能产生一个容易被猜到的 Session ID 值。此外，还需要经常重新生成 Session ID。在对安全性要求极高的场景下，例如转账等操作，除了使用 Session 管理用户状态之外，还需要对用户进行重新验证，比如重新输入密码，或者使用短信验证码等方式。

SQL注入攻击了解吗

• 攻击者在HTTP请求中注入恶意的SQL代码，服务器使用参数构建数据库SQL命令时，恶意SQL被一起构造，并在数据库中执行。
• 用户登录，输入用户名 wakk，密码 ‘ or ‘1’=’1 ，如果此时使用参数构造的方式，就会出现 select * from user where name = ‘lianggzone’ and password = ’ ‘or ‘1’=‘1’ 不管用户名和密码是什么内容，使查询出来的用户列表不为空。如何防范SQL注入攻击使用预编译的PrepareStatement是必须的，但是一般我们会从两个方面同时入手。
• Web端
  1. 有效性检验。
  2. 限制字符串输入的长度。
• 服务端
  1. 不用拼接SQL字符串。
  2. 使用预编译的PrepareStatement。
  3. 有效性检验。(为什么服务端还要做有效性检验？第一准则，外部都是不可信的，防止攻击者绕过Web端请求)
  4. 过滤SQL需要的参数中的特殊字符。比如单引号、双引号。

什么是RARP？工作原理

概括： 反向地址转换协议，网络层协议，RARP与ARP工作方式相反。 RARP使只知道自己硬件地址的主机能够知道其IP地址。
原理：
(1)网络上的每台设备都会有一个独一无二的硬件地址，通常是由设备厂商分配的MAC地址。主机从网卡上读取MAC地址，然后在网络上发送一个RARP请求的广播数据包，请求RARP服务器回复该主机的IP地址。
(2)RARP服务器收到了RARP请求数据包，为其分配IP地址，并将RARP回应发送给主机。
(3)收到RARP回应后，就使用得到的IP地址进行通讯。

端口有效范围是多少到多少

0-1023为知名端口号，比如其中HTTP是80，FTP是20（数据端口）、21（控制端口）
UDP和TCP报头使用两个字节存放端口号，所以端口号的有效范围是从0到65535。动态端口的范围是从1024到65535

为何需要把 TCP/IP 协议栈分成 5 层（或7层）？开放式回答。

答：ARPANET 的研制经验表明，对于复杂的计算机网络协议，其结构应该是层次式的。
分层的好处：
①隔层之间是独立的
②灵活性好
③结构上可以分隔开
④易于实现和维护
⑤能促进标准化工作。

HTTP中缓存的私有和共有字段？知道吗？

• private 指令规定了将资源作为私有缓存，只能被单独用户使用，一般存储在用户浏览器中。

Cache-Control: private

• public 指令规定了将资源作为公共缓存，可以被多个用户使用，一般存储在代理服务器中。

Cache-Control: public

GET 方法的长度限制是怎么回事

网络上都会提到浏览器地址栏输入的参数是有限的。
首先说明一点，HTTP 协议没有 Body 和 URL 的长度限制，对 URL 限制的大多是浏览器和服务器的原因。
浏览器原因就不说了，服务器是因为处理长 URL 要消耗比较多的资源，为了性能和安全（防止恶意构造长 URL 来攻击）考虑，会给 URL 长度加限制。

POST 方法比 GET 方法安全？

有人说POST 比 GET 安全，因为数据在地址栏上不可见。
然而，从传输的角度来说，他们都是不安全的，因为 HTTP 在网络上是明文传输的，只要在网络节点上捉包，就能完整地获取数据报文。
要想安全传输，就只有加密，也就是 HTTPS。

POST 方法会产生两个 TCP 数据包？你了解吗？

• 有些文章中提到，POST 会将 header 和 body 分开发送，先发送 header，服务端返回 100 状态码再发送 body。
• HTTP 协议中没有明确说明 POST 会产生两个 TCP 数据包，而且实际测试(Chrome)发现，header 和 body 不会分开发送。
• 所以，header 和 body 分开发送是部分浏览器或框架的请求方法，不属于 post 必然行为。

Session和cookie应该如何去选择（适用场景）

• Cookie 只能存储 ASCII 码字符串，而 Session 则可以存储任何类型的数据，因此在考虑数据复杂性时首选 Session；
• Cookie 存储在浏览器中，容易被恶意查看。如果非要将一些隐私数据存在 Cookie 中，可以将Cookie 值进行加密，然后在服务器进行解密；
• 对于大型网站，如果用户所有的信息都存储在 Session 中，那么开销是非常大的，因此不建议将所有的用户信息都存储到 Session 中。

Cookies和Session区别是什么

Cookie和Session都是客户端与服务器之间保持状态的解决方案

1. 存储的位置不同，cookie：存放在客户端，session：存放在服务端。Session存储的数据比较安全
2. 存储的数据类型不同 两者都是key-value的结构，但针对value的类型是有差异的 cookie：value只能是字符串类型，session：value是Object类型
3. 存储的数据大小限制不同 cookie：大小受浏览器的限制，很多是是4K的大小， session：理论上受当前内存的限制
4. 生命周期的控制
5. cookie的生命周期如果不设置过期时间，则表示这个cookie生命周期为浏览器会话期间，只要关闭浏览器窗口，cookie就消失了。这种生命期为浏览会话期的cookie被称为会话cookie。
6. 如果设置了过期时间，浏览器就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie依然有效直到超过设定的过期时间。存储在硬盘上的cookie可以在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存的cookie，不同的浏览器有不同的处理方式。
7. session的生命周期是间隔的，从创建时，开始计时如在20分钟，没有访问session，那么session生命周期被销毁

DDos 攻击了解吗？

1. 客户端向服务端发送请求链接数据包
2. 服务端向客户端发送确认数据包
3. 客户端不向服务端发送确认数据包
4. 服务器一直等待来自客户端的确认

没有彻底根治的办法，除非不使用TCP
DDos 预防： 1）限制同时打开SYN半链接的数目 2）缩短SYN半链接的Time out 时间 3）关闭不必要的服务

MTU和MSS分别是什么？

MTU：maximum transmission unit，最大传输单元，由硬件规定，如以太网的MTU为1500字节。
MSS：maximum segment size，最大分节大小，为TCP数据包每次传输的最大数据分段大小，一般由发送端向对端TCP通知对端在每个分节中能发送的最大TCP数据。MSS值为MTU值减去IPv4 Header（20 Byte）和TCP header（20 Byte）得到。

HTTP中有个缓存机制，但如何保证缓存是最新的呢？（缓存过期机制）

max-age 指令出现在请求报文，并且缓存资源的缓存时间小于该指令指定的时间，那么就能接受该缓存。
max-age 指令出现在响应报文，表示缓存资源在缓存服务器中保存的时间。

Cache-Control: max-age=31536000

Expires 首部字段也可以用于告知缓存服务器该资源什么时候会过期。

Expires: Wed, 04 Jul 2012 08:26:05 GMT

• 在 HTTP/1.1 中，会优先处理 max-age 指令；
• 在 HTTP/1.0 中，max-age 指令会被忽略掉。

TCP是什么

TCP（Transmission Control Protocol 传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议。

TCP头部中有哪些信息？

• 序号（32bit）：传输方向上字节流的字节编号。初始时序号会被设置一个随机的初始值（ISN），之后每次发送数据时，序号值 = ISN + 数据在整个字节流中的偏移。假设A -> B且ISN = 1024，第一段数据512字节已经到B，则第二段数据发送时序号为1024 + 512。用于解决网络包乱序问题。
• 确认号（32bit）：接收方对发送方TCP报文段的响应，其值是收到的序号值 + 1。
• 首部长（4bit）：标识首部有多少个4字节 * 首部长，最大为15，即60字节。
• 标志位（6bit）：
  • URG：标志紧急指针是否有效。
  • ACK：标志确认号是否有效（确认报文段）。用于解决丢包问题。
  • PSH：提示接收端立即从缓冲读走数据。
  • RST：表示要求对方重新建立连接（复位报文段）。
  • SYN：表示请求建立一个连接（连接报文段）。
  • FIN：表示关闭连接（断开报文段）。
• 窗口（16bit）：接收窗口。用于告知对方（发送方）本方的缓冲还能接收多少字节数据。用于解决流控。
• 校验和（16bit）：接收端用CRC检验整个报文段有无损坏。

常见TCP的连接状态有哪些

• CLOSED：初始状态。
• LISTEN：服务器处于监听状态。
• SYN_SEND：客户端socket执行CONNECT连接，发送SYN包，进入此状态。
• SYN_RECV：服务端收到SYN包并发送服务端SYN包，进入此状态。
• ESTABLISH：表示连接建立。客户端发送了最后一个ACK包后进入此状态，服务端接收到ACK包后进入此状态。
• FIN_WAIT_1：终止连接的一方（通常是客户机）发送了FIN报文后进入。等待对方FIN。
• CLOSE_WAIT：（假设服务器）接收到客户机FIN包之后等待关闭的阶段。在接收到对方的FIN包之后，自然是需要立即回复ACK包的，表示已经知道断开请求。但是本方是否立即断开连接（发送FIN包）取决于是否还有数据需要发送给客户端，若有，则在发送FIN包之前均为此状态。
• FIN_WAIT_2：此时是半连接状态，即有一方要求关闭连接，等待另一方关闭。客户端接收到服务器的ACK包，但并没有立即接收到服务端的FIN包，进入FIN_WAIT_2状态。
• LAST_ACK：服务端发动最后的FIN包，等待最后的客户端ACK响应，进入此状态。
• TIME_WAIT：客户端收到服务端的FIN包，并立即发出ACK包做最后的确认，在此之后的2MSL时间称为TIME_WAIT状态。

应用层常见协议知道多少？了解几个

协议	名称	默认端口	底层协议
HTTP	超文本传输协议	80	TCP
HTTPS	超文本传输安全协议	443	TCP
Telnet	远程登录服务的标准协议	23	TCP
FTP	文件传输协议	20传输和21连接	TCP
TFTP	简单文件传输协议	69	UDP
SMTP	简单邮件传输协议（发送用）	25	TCP
POP	邮局协议（接收用）	110	TCP
DNS	域名解析服务	53	服务器间进行域传输的时候用TCP
客户端查询DNS服务器时用 UDP

三次握手相关内容

• 初始状态：客户端处于 closed(关闭)状态，服务器处于 listen(监听) 状态。
• 第一次握手：客户端发送请求报文将 SYN = 1同步序列号和初始化序列号seq = x发送给服务端，发送完之后客户端处于SYN_Send状态。（验证了客户端的发送能力和服务端的接收能力）
• 第二次握手：服务端受到 SYN 请求报文之后，如果同意连接，会以自己的同步序列号SYN(服务端) = 1、初始化序列号 seq = y和确认序列号（期望下次收到的数据包）ack = x+ 1 以及确认号ACK = 1报文作为应答，服务器为SYN_Receive状态。（问题来了，两次握手之后，站在客户端角度上思考：我发送和接收都ok，服务端的发送和接收也都ok。但是站在服务端的角度思考：哎呀，我服务端接收ok，但是我不清楚我的发送ok不ok呀，而且我还不知道你接受能力如何呢？所以老哥，你需要给我三次握手来传个话告诉我一声。你要是不告诉我，万一我认为你跑了，然后我可能出于安全性的考虑继续给你发一次，看看你回不回我。）
• 第三次握手： 客户端接收到服务端的 SYN + ACK之后，知道可以下次可以发送了下一序列的数据包了，然后发送同步序列号 ack = y + 1和数据包的序列号 seq = x + 1以及确认号ACK = 1确认包作为应答，客户端转为established状态。（分别站在双方的角度上思考，各自ok）

为什么需要三次握手，两次不行吗？

如果是用两次握手，则会出现下面这种情况：

两次握手，客户端发送一次，服务端响应一次，链接就建立了，这种情况下服务端并没有确认客户端有接受能力，并且也不能保证客户端收到了。这时候假设信息中途丢失了或者客户端没有接受能力，客户端就会认为这次链接没建立，服务器没理他，而服务器认为建立了，苦苦等客户端发送下一次请求，这样就浪费了资源。

什么是半连接队列？

• 服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双方还没有完全建立其连接，服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。
• 当然还有一个全连接队列，就是已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。

这里在补充一点关于SYN-ACK 重传次数的问题： 服务器发送完SYN-ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传。如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。 注意，每次重传等待的时间不一定相同，一般会是指数增长，例如间隔时间为 1s，2s，4s，8s…

ISN(Initial Sequence Number)是固定的吗？

当一端为建立连接而发送它的SYN时，它为连接选择一个初始序号。ISN随时间而变化，因此每个连接都将具有不同的ISN，ISN是一个有可以看作是一个32比特的计数器，但并不是简单的计数器，大概每4ms加1 。

ISN = M + F(localhost, localport, remotehost, remoteport)(M为计数器)，ISN应该由这个公式确定，F为哈希算法，不是一个简单计数器。

三次握手的其中一个重要功能是客户端和服务端交换 ISN(Initial Sequence Number)，以便让对方知道接下来接收数据的时候如何按序列号组装数据。如果 ISN 是固定的，攻击者很容易猜出后续的确认号，因此 ISN 是动态生成的。

三次握手过程中可以携带数据吗？

第一次、第二次握手不可以携带数据,。
对** 服务端 **来说 如果有人第一次握手就SYN报文内携带大量数据，恶意攻击，在没建立连接的情况下，服务器要花费大量时间空间来接收这些报文。
对 **客户端 **来说 第三次握手时才确定服务器的接收发送能力是否正常，才能确定发过去的内容服务器能接收。

SYN攻击是什么？

服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。SYN 攻击是一种典型的 DoS/DDoS 攻击。
检测 SYN 攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击。在 Linux/Unix 上可以使用系统自带的 netstats 命令来检测 SYN 攻击。

netstat -n -p TCP | grep SYN_RECV

常见的防御 SYN 攻击的方法有如下几种：

• 缩短超时（SYN Timeout）时间
• 增加最大半连接数
• 过滤网关防护
• SYN cookies技术