计算机网络相关（持续更新）

秋招后的一些记录，看了很多东西想写下来，希望自己可以随时的查看，也希望有错误的地方大神可以指正。

1、HTTP有哪些方法及具体作用

HTTP1.0定义了三种请求方法

GET：通常用于请求服务器发送某些资源。

POST：发送数据给服务器。

HEAD：请求资源的头部信息, 并且这些头部与 HTTP GET 方法请求时返回的一致. 该请求方法的一个使用场景是在下载一个大文件前先获取其大小再决定是否要下载, 以此可以节约带宽资源。

HTTP1.1新增了五种请求方法

OPSTIONS：用于获取目的资源所支持的通信选项。

PUT：用于新增资源或者使用请求中的有效负载替换目标资源的表现形式。

DELETE：用于删除指定的资源。

TRACE：回显服务器收到的请求，主要用于测试或诊断。

CONNECT：HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。

PATCH：用于对资源进行部分修改。

2、GET和POST有什么区别

1、数据传输方式不同：GET请求通过URL传输数据，而POST的数据通过请求体传输。

2、安全性不同：POST的数据因为在请求主体内，所以有一定的安全性保证，而GET的数据在URL中，通过历史记录，缓存很容易查到数据信息。

3、数据类型不同：GET只允许 ASCII 字符，而POST无限制。

4、get 请求会被浏览器主动 cache，而 post 不会，除非手动设置。

5、GET无害(重复提交的问题)： 刷新、后退等浏览器操作GET请求是无害的，POST可能重复提交表单。

6、特性不同：

（1）安全：指只读特性，就是使用这个方法不会引起服务器状态变化。

（2）幂等：是指同一个请求方法执行多次和仅执行一次的效果完全相同。

（3）GET安全且幂等但是POST不是。

7、get 请求在发送过程中会产生一个 TCP 数据包；post 在发送过程中会产生两个 TCP 数据包

（1）对于 get 方式的请求，浏览器会把 http header 和 data 一并发送出去，服务器响应 200（返回数据）。

（2）而对于 post，浏览器先发送 header，服务器响应 100 continue，浏览器再发送 data，服务器响应 200 ok（返回数据）。post发两个tcp包也只是部分浏览器行为，与http协议无关。post先去检测一下服务器是否能正常应答，然后再把data携带过去，如果应答不了，就没有了第二步数据传输。

3、PUT和POST都是给服务器发送新增资源有何不同

幂等性：PUT幂等而POST不幂等。

PUT的URI指向是具体单一资源，而POST可以指向资源集合。

4、PUT和PATCH都是给服务器发送修改资源有何不同

PATCH用来对已知资源进行局部更新。

PUT是对资源直接进行覆盖式修改。

5、HTTP的请求报文是什么样的

**请求行：**请求方法、URL字段、HTTP协议版本字段

    例如：GET /index.html HTTP/1.1
    
    
      
    
    AI写代码

**请求头部：****关键字/值对组成

例如：
User-Agent：产生请求的浏览器类型。
Accept：客户端可识别的内容类型列表。
Host：请求的主机名，允许多个域名同处一个IP地址，即虚拟主机。

**空行：**很重要，用来区分开头部和实体。

**请求体：**post put等请求携带的数据。

问: 如果说在头部中间故意加一个空行会怎么样？

那么空行后的内容全部被视为实体。

6、HTTP的响应报文是什么样的

**响应行：**协议版本、状态码、状态码原因语句

    例如：HTTP/1.1    200    OK
    
    
      
    
    AI写代码

**响应头：**响应首部组成。

**空行：**很重要，用来区分开头部和实体。

**响应体：**服务器响应数据。

7、HTTP首部有哪些

通用首部字段（General Header Fields）

请求报文和响应报文两方都会使用的首部

Cache-Control ： 控制缓存

Connection： 连接管理、逐条首部

Upgrade ：升级为其他协议

via ：代理服务器的相关信息

Wraning ：错误和警告通知

Transfor-Encoding： 报文主体的传输编码格式

Trailer： 报文末端的首部一览

Pragma： 报文指令

Date： 创建报文的日期

请求首部字段（Reauest Header Fields）

客户端向服务器发送请求的报文时使用的首部

Accept：客户端或者代理能够处理的媒体类型

Accept-Encoding ：优先可处理的编码格式

Accept-Language： 优先可处理的自然语言

Accept-Charset ：优先可以处理的字符集

If-Match ：比较实体标记（ETage）

If-None-Match ： 比较实体标记（ETage）与 If-Match相反

If-Modified-Since ：比较资源更新时间（Last-Modified）

If-Unmodified-Since：比较资源更新时间（Last-Modified），与 If-Modified-Since相反

If-Rnages ： 资源未更新时发送实体byte的范围请求

Range ：实体的字节范围请求

Authorization ：web的认证信息

Proxy-Authorization： 代理服务器要求web认证信息

Host： 请求资源所在服务器

From： 用户的邮箱地址

User-Agent： 客户端程序信息

Max-Forwrads ：最大的逐跳次数

TE： 传输编码的优先级

Referer ：请求原始放的url

Expect ：期待服务器的特定行为

响应首部字段（Response Header Fields）

从服务器向客户端响应时使用的字段

Accept-Ranges ：能接受的字节范围

Age ：推算资源创建经过时间

Location ：令客户端重定向的URI

vary ： 代理服务器的缓存信息

ETag： 能够表示资源唯一资源的字符串

WWW-Authenticate ：服务器要求客户端的验证信息

Proxy-Authenticate ：代理服务器要求客户端的验证信息

Server ：服务器的信息

Retry-After： 和状态码503 一起使用的首部字段，表示下次请求服务器的时间

实体首部字段（Entiy Header Fields）

针对请求报文和响应报文的实体部分使用首部

Allow ：资源可支持http请求的方法

Content-Language： 实体的资源语言

Content-Encoding： 实体的编码格式

Content-Length ：实体的大小（字节）

Content-Type ：实体媒体类型

Content-MD5 ：实体报文的摘要

Content-Location： 代替资源的yri

Content-Rnages： 实体主体的位置返回

Last-Modified： 资源最后的修改资源

Expires ：实体主体的过期资源

8、HTTP状态码有哪些

1xx（表示目前是协议处理的中间状态，还需要后续操作）

101 Switching Protocols：在HTTP升级为WebSocket的时候，如果服务器同意变更，就会发送状态码 101。

2xx（表示成功状态）

200 OK：是见得最多的成功状态码。通常在响应体中放有数据。

201 Created：请求已经被实现，而且有一个新的资源已经依据请求的需要而建立。

202 Accepted：求已接受，但是还没执行，不保证完成请求。

204 No content：含义与 200 相同，但响应头后没有 body 数据。

206 Partial Content：顾名思义，表示部分内容，它的使用场景为 HTTP 分块下载和断点续传，当然也会带上相应的响应头字段Content-Range。

3xx（重定向状态，资源位置发生变动，需要重新请求）

301 moved permanently：永久性重定向，表示资源已被分配了新的 URL。比如你的网站从 HTTP 升级到了 HTTPS 了，以前的站点再也不用了，应当返回301，这个时候浏览器默认会做缓存优化，在第二次访问的时候自动访问重定向的那个地址。

302 found：临时性重定向，表示资源临时被分配了新的 URL。而如果只是暂时不可用，那么直接返回302即可，和301不同的是，浏览器并不会做缓存优化。

303 see other：表示资源存在着另一个 URL，应使用 GET 方法定向获取资源（临时）。

304 not modified：当协商缓存命中时会返回这个状态码。

307 temporary redirect：临时重定向，和302含义相同。

4xx（客户端错误，请求报文有误）

400 bad resquest：请求报文存在语法错误 。

401 unauthorized：表示发送的请求需要有通过 HTTP 认证的认证信息。

403 forbidden：表示对请求资源的访问被服务器拒绝(原因有很多，比如法律禁止、信息敏感)。

404 not found：资源未找到，表示没在服务器上找到相应的资源。

405 Method Not Allowed：请求方法不被服务器端允许。

406 Not Acceptable：资源无法满足客户端的条件。

408 Request timeout：服务器等待了太长时间。

409 Confict：多个请求发生了冲突。

413 Request Entity Too Large：请求体的数据过大。

414 Request-URI Too Long：请求行里的 URI 太大。

429 Too Many Request：客户端发送的请求过多。

431 Request Header Fields Too Large：请求头的字段内容太大。

5xx（服务器端发生错误）

500 internal server rror：表示服务器端在执行请求时发生了错误。

501 Not implemented：表示客户端请求的功能还不支持。

502 Bad Gateway： 服务器自身是正常的，但访问的时候出错了。

503 service unavailable：表示服务器当前很忙，暂时无法响应服务。

505 http version not supported：服务器不支持，或者拒绝支持在请求中使用的 HTTP 版本。

9、同样是重定向307，303，302的区别

1、302是http1.0的协议状态码，在http1.1版本的时候为了细化302状态码又出来了两个303和307。

2、303明确表示客户端应当采用get方法获取资源，他会把POST请求变为GET请求进行重定向。 307会遵照浏览器标准，不会从post变为get。

10、HTTP的keep-alive是干什么的

keep-alive是什么：保持长连接

keep-alive的优点：

（1）较少的CPU和内存的使用（由于同时打开的连接的减少了）

（2）允许请求和应答的HTTP管线化

（3）降低拥塞控制 （TCP连接减少了）

（4）减少了后续请求的延迟（无需再进行握手）

（5）报告错误无需关闭TCP连

11、HTTPS

http需要详细介绍,这里只是简单介绍一下

可以看这个我觉得还不错:https://segmentfault.com/a/1190000018992153

1、对称加密和非对称加密。

2、对称加密和非对称加密的结合。

3、添加数字证书。

4、总结：HTTPS并不是一个新的协议, 它在HTTP和TCP的传输中建立了一个安全层，利用对称加密和非对称加密结合数字证书认证的方式，让传输过程的安全性大大提高。

12、HTTP 和 HTTPS 的区别

HTTP 是一种 超文本传输协议(Hypertext Transfer Protocol)，HTTP 是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范。

HTTP 主要内容分为三部分，超文本（Hypertext）、传输（Transfer）、协议（Protocol）：

（1）超文本就是不单单只是文本，它还可以传输图片、音频、视频，甚至点击文字或图片能够进行超链接的跳转。

（2）上面这些概念可以统称为数据，传输就是数据需要经过一系列的物理介质从一个端系统传送到另外一个端系统的过程。通常我们把传输数据包的一方称为请求方，把接到二进制数据包的一方称为应答方。

（3）而协议指的就是是网络中(包括互联网)传递、管理信息的一些规范。如同人与人之间相互交流是需要遵循一定的规矩一样，计算机之间的相互通信需要共同遵守一定的规则，这些规则就称为协议，只不过是网络协议。

HTTPS 的全称是 Hypertext Transfer Protocol Secure ：它其实就是 HTTP + TLS/SSL 协议组合而成，而安全性的保证正是 TLS/SSL 所做的工作。

区别：

（1）地址栏开头。

（2）HTTP 的默认端口是 80，而 HTTPS 的默认端口是 443。

13、对称加密算法

对称加密算法：利用对称加密算法，可以将明文数据和加密密钥一起，经过特殊加密算法处理，使其变成复杂的加密密文发送出去。对方收到密文后，需要使用加密用过的密钥及相同算法的逆算法对密文进行解密，才能使其恢复成可读明文。

算法：

（1）DES：

DES算法全称为Data Encryption Standard，即数据加密算法，DES加密算法是IBM公司于1975年研究成功并公开发表的。DES算法的入口参数有三个：Key、Data、Mode。其中Key为8个字节共64位，是DES算法的工作密钥；Data也为8个字节64位，是要被加密或被解密的数据。Mode为DES的工作方式,有两种：加密或解密。

DES算法把64位的明文输入块变为64位的密文输出块，它所使用的密钥也是64位，其算法主要分为两步：

1、初始置换：其功能是把输入的64位数据块按位重新组合,并把输出分为L0、R0两部分，每部分各长32位，其置换规则为将输入的第58位换到第一位，第50位换到第2位……依此类推,最后一位是原来的第7位。L0、R0则是换位输出后的两部分，L0是输出的左32位，R0是右32位，例：设置换前的输入值为D1D2D3……D64，则经过初始置换后的结果为:L0=D58D50……D8；R0=D57D49……D7。

2、逆置换：经过16次迭代运算后，得到L16、R16,将此作为输入，进行逆置换，逆置换正好是初始置换的逆运算，由此即得到密文输出。

（2）3DES： 3DES（Triple DES）是三重数据加密算法（TDEA）密码的通称。它相当于是对每个数据块应用三次DES加密算法。由于计算机运算能力的增强，原版DES密码的密钥长度变得容易被暴力破解；3DES通过增加DES的密钥长度来避免类似的攻击，而不是设计一种全新的块密码算法。

（3）AES： AES：又称Rijndael加密法，是美国联邦政府采用的一种区块加密标准。用来替代原先的DES。目前已然成为对称密钥加密中的算法之一。

（4）RC2： RC2是由密码学家Ron Rivest设计的一种传统对称分组加密算法，它可作为DES算法的建议替代算法。它的输入和输出都是64比特。密钥的长度是从1字节到128字节可变。

（5）RC4：RC4加密算法是大名鼎鼎的RSA三人组中的头号人物Ronald Rivest在1987年设计的密钥长度可变的流加密算法簇。由于RC4核心部分的S-box长度可为任意，该算法的速度可以达到DES加密的10倍左右，且具有很高级别的非线性。

（6）RC5： RC5分组密码算法是1994由麻萨诸塞技术研究所的Ronald L. Rivest教授发明的，并由RSA实验室分析。它是参数可变的分组密码算法，三个可变的参数是：分组大小、密钥大小和加密轮数。在RC5算法中使用了三种运算：异或、加和循环。

介绍：

优点：算法公开、计算量小、加密速度快、加密效率高。

（1）交易双方都使用同样钥匙，安全性得不到保证。

（2）每对用户每次使用对称加密算法时，都需要使用其他人不知道的惟一钥匙，这会使得发收信双方所拥有的钥匙数量呈几何级数增长，密钥管理成为用户的负担。对称加密算法在分布式网络系统上使用较为困难，主要是因为密钥管理困难，使用成本较高。

14、HTTP的缓存过程

1、客户端向服务端请求资源。

2、服务端返回资源，并通过响应头决定缓存策略。

3、客户端根据响应头决定是否缓存资源。

4、客户端再次请求时，客户端就去检查上次的缓存策略（是否过期等去判断读取本地还是与服务器协商缓存）

15、强缓存与协商缓存

强缓存

不会向服务器发送请求，直接从缓存中读取资源

强缓存离不开两个响应头 ： Expires 与 Cache-Control

**Expires：**Expires是http1.0提出的一个表示资源过期时间的header，它描述的是一个绝对时间，由服务器返回，Expires 受限于本地时间，如果修改了本地时间，可能会造成缓存失效。

    Expires: Wed, 11 May 2020 07:00:00 GMT
    
    
      
    
    AI写代码

Cache-Control: Cache-Control 出现于 HTTP / 1.1，优先级高于 Expires ,表示的是相对时间

    Cache-Control: max-age=1314520
    
    
      
    
    AI写代码

Cache-Control:

public：可以被所有用户缓存 。表明任何情况下都得获得缓存资源（即使是需要HTTP人证的资源）

**private：只被终端浏览器缓存。**表明返回报文中全部或部分（若指定了field-name则为field-name的字段数据）仅开放给某些用户（share-user，如代理服务器）做缓存使用，其他用户则不能缓存这些数据。

**no-cache：先缓存本地。**不直接使用缓存，要向服务器发起（新鲜度校验）请求。

no-store：不产生任何缓存 。所有内容都不会被保存到缓存或internet临时文件中。

在缓存有效期内命中缓存，浏览器会直接读取本地的缓存资源，当缓存过期之后会与服务器进行协商。

协商缓存

无命中强缓存(有资源但不确定是否是最新的)

当第一次请求时服务器返回的响应头中没有Cache-Control和Expires或者Cache-Control和Expires过期抑或它的属性设置为no-cache时，那么浏览器第二次请求时就会与服务器进行协商。

如果缓存和服务端资源的最新版本是一致的，那么就无需再次下载该资源，服务端直接返回304 Not Modified 状态码，如果服务器发现浏览器中的缓存已经是旧版本了，那么服务器就会把最新资源的完整内容返回给浏览器，状态码就是200 Ok。（新资源返回200 ok，没有更新让客户端读取本地就是304 ）。

Last-Modified（响应）/If-Modified-Since（请求） ：

时间上的比对。

客户端首次请求资源时，服务器会把资源的最新修改时间

    Last-Modified:Thu, 19 Feb 2020 07:20:00 GMT
    
    
      
    
    AI写代码

通过响应部首发送给客户端，当再次发送请求是，客户端将服务器返回的修改时间放在请求头

    If-Modified-Since:Thu, 19 Feb 2020 07:20:00 GMT
    
    
      
    
    AI写代码

发送给服务器，服务器再跟服务器上的对应资源进行比对，如果服务器的资源更新，那么返回最新的资源，此时状态码200，当服务器资源跟客户端的请求的部首时间一致，证明客户端的资源是最新的，返回304状态码，表示客户端直接用缓存即可。

ETag（响应）/If-None-Match（请求） ：

更具资源内容进行hash比对。

ETag的流程跟Last-Modified是类似的，区别就在于ETag是根据资源内容进行hash，生成一个信息摘要，只要资源内容有变化，这个摘要就会发生巨变，通过这个摘要信息比对，即可确定客户端的缓存资源是否为最新，这比Last-Modified的精确度要更高。

ETag 优先级高于Last-Modified。

流程：

（简单说明）

16、简述 HTTP1.0/1.1/2.0 的区别

HTTP 1.0

1、HTTP 1.0 仅仅提供了最基本的认证，这时候用户名和密码还未经加密，因此很容易收到窥探。

2、HTTP 1.0 被设计用来使用短链接，即每次发送数据都会经过 TCP 的三次握手和四次挥手，效率比较低。

3、HTTP 1.0 只使用 header 中的 If-Modified-Since 和 Expires 作为缓存失效的标准。

4、HTTP 1.0 不支持断点续传，也就是说，每次都会传送全部的页面和数据。

5、HTTP 1.0 认为每台计算机只能绑定一个 IP，所以请求消息中的 URL 并没有传递主机名。

HTTP 1.1

1、HTTP 1.1 使用了摘要算法来进行身份验证。

2、HTTP 1.1 默认使用长连接，长连接就是只需一次建立就可以传输多次数据，传输完成后，只需要一次切断连接即可。长连接的连接时长可以通过请求头中的 keep-alive 来设置。

3、HTTP 1.1 中新增加了 E-tag，If-Unmodified-Since, If-Match, If-None-Match 等缓存控制标头来控制缓存失效。

4、HTTP 1.1 支持断点续传，通过使用请求头中的 Range 来实现。

5、HTTP 1.1 使用了虚拟网络，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。

HTTP 2.0

**1、头部压缩：**由于 HTTP 1.1 经常会出现 User-Agent、Cookie、Accept、Server、Range 等字段可能会占用几百甚至几千字节，而 Body 却经常只有几十字节，所以导致头部偏重。HTTP 2.0 使用 HPACK 算法进行压缩。

**2、二进制格式：**HTTP 2.0 使用了更加靠近 TCP/IP 的二进制格式，而抛弃了 ASCII 码，提升了解析效率。

**3、强化安全：**由于安全已经成为重中之重，所以 HTTP2.0 一般都跑在 HTTPS 上。

**4、多路复用：**即每一个请求都是是用作连接共享。一个请求对应一个id，这样一个连接上可以有多个请求。

17、UDP 和 TCP 的区别

UDP 是什么

UDP 的全称是 User Datagram Protocol，用户数据报协议。

它不需要所谓的握手操作，从而加快了通信速度，允许网络上的其他主机在接收方同意通信之前进行数据传输。数据报是与分组交换网络关联的传输单元。

UDP 的特点主要有：

（1）UDP 能够支持容忍数据包丢失的带宽密集型应用程序。

（2）UDP 具有低延迟的特点。

（3）UDP 能够发送大量的数据包。

（4）UDP 能够允许 DNS 查找，DNS 是建立在 UDP 之上的应用层协议。

TCP 是什么

TCP 的全称是Transmission Control Protocol ，传输控制协议。

它能够帮助你确定计算机连接到 Internet 以及它们之间的数据传输。

TCP 的主要特点有：

（1）TCP 能够确保连接的建立和数据包的发送

（2）TCP 支持错误重传机制

（3）TCP 支持拥塞控制，能够在网络拥堵的情况下延迟发送

（4）TCP 能够提供错误校验和，甄别有害的数据包

区别

（1）TCP 是面向连接的协议 。 UDP 是无连接的协议

（2）TCP 在发送数据前先需要建立连接，然后再发送数据 。 UDP 无需建立连接就可以直接发送大量数据

（3）TCP 会按照特定顺序重新排列数据包 。 UDP 数据包没有固定顺序，所有数据包都相互独立

（4）TCP 传输的速度比较慢 。 UDP 的传输会更快

（5）TCP 的头部字节有 20 字节 。 UDP 的头部字节只需要 8 个字节

（6）TCP 是重量级的，在发送任何用户数据之前，TCP需要三次握手建立连接。 UDP 是轻量级的。没有跟踪连接，消息排序等。

（7）TCP 会进行错误校验，并能够进行错误恢复 。 UDP 也会错误检查，但会丢弃错误的数据包

（8）TCP 有发送确认。 UDP 没有发送确认

（9）TCP 会使用握手协议，例如 SYN，SYN-ACK，ACK。 UDP无握手协议

（10）TCP 是可靠的，因为它可以确保将数据传送到路由器。 UDP 中不能保证将数据传送到目标。

18、OSI七层模型

应用层、表示层、会话层、传输层、网络层、数据链路层、物理层

19、三次握手

1、过程

1、客户端->服务端 （SYN = 1，seq=x）（序列号seq） （此时客户端处于SYN_SEND状态）。

2、服务端 -> 客户端 （SYN=1，ACK=1，seq =y,ACKnum = x+1）（ACKnum确认序列号） （此时服务端处于 SYN_REVD状态）。

3、客户端 -> 服务端 （ACK =1 ，ACKnum =y+1） （两端都处于 ESTABLISHED）。

2、目的作用拓展

1、三次握手其实就是建立一个TCP连接时，需要客户端和服务器总共发送3个包。

2、主要作用就是为了确认双方的就收能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备。

3、实质上其实就是连接服务器指定端口，建立TCP连接，并同步连接双方的序列号和确认号，交互TCP窗口大小信息。

3、为什么需要三次握手两次不行？

解释需要客户端有接收信息的能力正常。

模拟场景如何第一次丢失（网络节点延迟了），第一次成功后建立了也释放了连接，又收到了第一次请求，建立了连接，消耗资源。

4、什么是半连接队列

服务器第一次收到客户端SYN之后就会处于一个 SYN_RCVD状态，此时双方没有建立连接，服务器把这种状态放在一个队列（半连接队列）中。

全连接队列（完成三次握手，建立起的连接就会放在全连接队列中，如果满了可能会出现丢包的情况）。

SYN——ACK重传次数的问题：

服务器发送完SYN-ACK包之后，如果没有收到客户端的确认包就会进行重传。

重传的待的时间一般不一定相同，一般会是指数增长（1s，2s，4s，8s）。重传次数超过系统规定的最大重传次数，系统将连接信息从半连接队列中删除。

5、ISN是固定的吗？

ISN是动态生成的。

6、三次握手可以携带数据吗？

第三次可以携带数据，前两次是不可以的。

第一次带了数据，服务器很容易被攻击，其他人就一直请求服务器让服务器解析数据。

第三次可以带数据因为对于客户端来说，他已经建立连接了，并且服务端接收和发送数据的能力正常。

7、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。

常见的防御方法如下：

（1）缩短超时（SYN Timeout）时间

（2）增加最大半连接数

（3）过滤网官防护

（4）SYN cookies技术

20、四次挥手

1、过程

客户端 -> 服务端 （FIN = 1，seq =x）

服务端 -> 客户端 （ACK =1，ACKnum = x+1）

服务端 -> 客户端 （FIN=1，seq = y）

客户端 -> 服务端 （ACK =1，ACKnum =y+1）

2、为什么挥手需要四次

关闭连接时，当服务端收到FIN报文时，可能并不会立即关闭SOCKET，所以要先回复一个ACK报文，告诉客户端收到了。只有等到服务端所有的报文都发送完了，才能发送FIN报文，因此不能一起发送。

3、2MSL等待状态

每个具体TCP实现必须选择一个报文段最大生存时间MSL（Maximum Segment Lifetime）。

这样可以让TCP再次发送最后的ACK以防这个ACK丢失（另外一端超时重发这个FIN）。

这会导致一个结果就是这个TCP连接在2MSL期间定义这个连接的插口（客户端IP，端口，服务器IP，端口）不能再被使用。只有结束后才能使用。

4、等待2MSL的意义

MSL是Maximum Segment Lifetime的英文缩写，可译为“最长报文段寿命”

它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。

为了保证最后一个ACK报文能够到达服务端。

2MSL中如果服务端没有收到就会超时重发，接着客户端重传一次确认，重新启动时间等待计时器。如果不等待，服务器没有收到ACK确认报文，服务器就无法正常进入关闭状态。

防止“已失效的连接请求报文段”出现本地连接中。

客户端再发送完最后一个ACK报文段后，再经过2MSL，就可以使本地连接持续的时间所产生的所有报文段从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文。

为什么TIME_WAIT状态需要经过2MSL才能返回到CLOSE状态？

理论上，四个报文都发送完毕，就可以直接进入CLOSE状态了，但是可能网络是不可靠的，有可能最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

21、TCP 快速打开的原理(TFO)

TFO的流程

首次三次握手：

区别与正常三次握手的是，第二次服务端不会立刻回复SYN+ACK，而是通过计算得到一个SYN Cookie，将这个cookie放到TCP的报文的Fast Open选项中，然后再发给客户端，客户端拿到这个cookie之后缓存下来。后面完成三次握手。

后续三次握手：

1、后续的三次握手才是体现快速打开。

2、后面的三次握手客户端直接将之前缓存的cookie、SYN和http请求发给服务端，服务端验证cookie的合法性，如果合法那就返回SYN+ACK。

3、重点再这里。客户端与服务端还没有完成三次握手但是因为它验证了cookie的合法性所以现在就可以返回HTTP响应了。

注意：最后一次握手客户端还是会将ACK正常传过去，完成三次握手。

注意: 客户端最后握手的 ACK 不一定要等到服务端的 HTTP 响应到达才发送，两个过程没有任何关系。

TFO的优势

TFO 的优势并不在与首轮三次握手，而在于后面的握手，在拿到客户端的 cookie 并验证通过以后，可以直接返回 HTTP 响应，充分利用了1 个RTT(Round-Trip Time，往返时延)的时间提前进行数据传输。

22、TCP报文中时间戳的作用

timestamp是 TCP 报文首部的一个可选项，一共占 10 个字节，格式如下:
kind(1 字节) + length(1 字节) + info(8 个字节)

其中 kind = 8， length = 10， info 有两部分构成: timestamp和timestamp echo，各占 4 个字节。

TCP 的时间戳主要解决两大问题:

计算往返时延 RTT(Round-Trip Time)

防止序列号的回绕问题

后续更新详细介绍

23、TCP 的超时重传时间

TCP 具有超时重传机制，即间隔一段时间没有等到数据包的回复时，重传这个数据包。

这个重传间隔也叫做超时重传时间(Retransmission TimeOut, 简称RTO)。

计算方法：

经典法：

后续更新

标准法：

后续更新

24、TCP粘包

后续更新

25、TCP 的 keep-alive

当看见keep-alive的时候，大多数都会觉得是Http的keep-alive。不过 TCP 层面也是有keep-alive机制。

但是在我看来其实他没有什么作用，但是我们知道一点还是比较好的。

当有一方因为网络故障或者宕机导致连接失效，由于 TCP 并不是一个轮询的协议，在下一个数据包到达之前，对端对连接失效的情况是一无所知的。

这个时候就出现了 keep-alive, 它的作用就是探测对端的连接有没有失效。

不过，现状是大部分的应用并没有默认开启 TCP 的keep-alive选项，原因：

7200s 也就是两个小时检测一次，时间太长。

时间再短一些，也难以体现其设计的初衷, 即检测长时间的死连接。

26、TCP 的流量控制

介绍

对于发送端和接收端而言，TCP 需要把发送的数据放到发送缓存区, 将接收的数据放到接收缓存区。

而流量控制所要做的事情，就是在通过接收缓存区的大小，控制发送端的发送。如果对方的接收缓存区满了，就不能再继续发送了。

TCP滑动窗口

TCP 滑动窗口分为两种: 发送窗口和接收窗口。

发送窗口：

发送端的滑动窗口结构如下:

其中包含四大部分:

已发送且已确认
已发送但未确认
未发送但可以发送
未发送也不可以发送

发送窗口就是图中被框住的范围。SND 即send, WND 即window, UNA 即unacknowledged, 表示未被确认，NXT 即next, 表示下一个发送的位置。

接收窗口：

接收端的窗口结构如下:

REV 即 receive，NXT 表示下一个接收的位置，WND 表示接收窗口大小。

27、TCP 的拥塞控制

介绍

流量控制发生在发送端跟接收端之间，并没有考虑到整个网络环境的影响，如果说当前网络特别差，特别容易丢包，那么发送端就应该注意一些了。而这，也正是拥塞控制需要处理的问题。

两个核心状态

拥塞窗口（Congestion Window，cwnd） ：

1、是指目前自己还能传输的数据量大小。

2、接收窗口(rwnd)是接收端给的限制、拥塞窗口(cwnd)是发送端的限制。

3、限制的是发送窗口的大小。

发送窗口大小 = min(rwnd, cwnd)。取两者的较小值。而拥塞控制，就是来控制cwnd的变化。

慢启动阈值（Slow Start Threshold，ssthresh）

它的阈值叫做慢启动阈值，当 cwnd 到达这个阈值之后，好比踩了下刹车。

涉及到的算法

慢启动 ：

刚开始进入传输数据的时候，你是不知道现在的网路到底是稳定还是拥堵的，如果做的太激进，发包太急，那么疯狂丢包，造成雪崩式的网络灾难。

首先，三次握手，双方宣告自己的接收窗口大小
双方初始化自己的拥塞窗口(cwnd)大小
在开始传输的一段时间，发送端每收到一个 ACK，拥塞窗口大小加 1，也就是说，每经过一个 RTT，cwnd 翻倍。如果说初始窗口为 10，那么第一轮 10 个报文传完且发送端收到 ACK 后，cwnd 变为 20，第二轮变为 40，第三轮变为 80，依次类推。

拥塞避免

原来每收到一个 ACK，cwnd 加1，现在到达阈值了，cwnd 只能加这么一点: 1 / cwnd。那你仔细算算，一轮 RTT 下来，收到 cwnd 个 ACK, 那最后拥塞窗口的大小 cwnd 总共才增加 1。
也就是说，以前一个 RTT 下来，cwnd翻倍，现在cwnd只是增加 1 而已。
当然，慢启动和拥塞避免是一起作用的，是一体的。

快速重传和快速恢复

快速重传：

比如第 5 个包丢了，即使第 6、7 个包到达的接收端，接收端也一律返回第 4 个包的 ACK。当发送端收到 3 个重复的 ACK 时，意识到丢包了，于是马上进行重传，不用等到一个 RTO 的时间到了才重传。（RTO：超时重传时间）。

这就是快速重传，它解决的是是否需要重传的问题。

选择性重传：

在收到发送端的报文后，接收端回复一个 ACK 报文，那么在这个报文首部的可选项中，就可以加上SACK这个属性，通过left edge和right edge告知发送端已经收到了哪些区间的数据报。

因此，即使第 5 个包丢包了，当收到第 6、7 个包之后，接收端依然会告诉发送端，这两个包到了。剩下第 5 个包没到，就重传这个包。这个过程也叫做选择性重传(SACK，Selective Acknowledgment)，它解决的是如何重传的问题。

快速恢复：

发送端收到三次重复 ACK 之后，发现丢包，觉得现在的网络已经有些拥塞了，自己会进入快速恢复阶段。

在这个阶段，发送端如下改变：

拥塞阈值降低为 cwnd 的一半
cwnd 的大小变为拥塞阈值
cwnd 线性增加（cwnd：拥塞窗口）

28、DNS解析过程

1、浏览器检查缓存种有没有这个域名对应的解析过的ip地址，如果有该解析过程将会结束。

2、检查本地的hosts文件是否有这个网址映射关系。

3、如果hosts种没有这个域名映射，查找本地DNS解析器缓存，如果有直接返回。

4、通过首选DNS服务器(本地域名服务器)，以递归或循环的方式查询域名对应的ip地址并返回。(顶级域，二级域，三级域)。

递归查询：本机向本地域名服务器发出一次查询请求，就静待最终的结果。如果本地域名服务器无法解析，自己会以DNS客户机的身份向其它域名服务器查询，直到得到最终的IP地址告诉本机。

迭代查询：本地域名服务器向根域名服务器查询，根域名服务器告诉它下一步到哪里去查询，然后它再去查，每次它都是以客户机的身份去各个服务器查询。

29、Cache-Control: no-cache

响应头的no-cache表达的是可以缓存。

先缓存本地。

图片会发出请求头带上If-Modified-Since: Tue, 08 Nov 2016 06:59:00 GMT。

服务器确认新鲜度，如果客户端资源是新鲜资源则返回304,否则返回200并带上新的图片资源。