找工作系利之-计算机网络

待解决

Ping和TraceRoute实现原理

(1) Ping是通过发送ICMP报文回显请求实现。
(2) TraceRoute通过发送UDP报文，设置目的端口为一个不可能的值，将IP首部中的TTL分别设置从1到N，每次逐个增加，如果收到端口不可达，说明到达目的主机，如果是因为TTL跳数超过，路由器会发送主机不可达的ICMP报文。

每层协议

数据链路层：PPP HDLC
网络层：ICMP

PARP的实现

常见的攻击方法

• SQL注入
• XSS
• CSRF
• SYN洪水攻击
• APR欺骗

网络层

传输层

TCP三次握手四次挥手的过程，为什么tcp连接握手需要三次, time_wait状态

1）TCP连接（三次握手）过程：
客户端A：发送SYN连接报文，序列号为x，进入SYNC-SENT状态。

服务端B：发送SYN连接确认报文（SYN=1，ACK = 1），序列号为y（seq = y），确认报文x（ack = x + 1），进入SYNC-RCVD状态。

客户端A：发送ACK确认报文（ACK = 1），序列号为x+1（seq = x + 1），确认报文y+1（ack = y + 1），进入ESTABLISHED状态。

服务器B：收到后进入ESTABLISHED状态。

2）三次握手原因：

三次握手是为了防止，客户端的请求报文在网络滞留，客户端超时重传了请求报文，服务端建立连接，传输数据，释放连接之后，服务器又收到了客户端滞留的请求报文，建立连接一直等待客户端发送数据。

服务器对客户端的请求进行回应(第二次握手)后，就会理所当然的认为连接已建立，而如果客户端并没有收到服务器的回应呢？此时，客户端仍认为连接未建立，服务器会对已建立的连接保存必要的资源，如果大量的这种情况，服务器会崩溃。

3） TCP释放（四次分手）过程：

服务端A：发送FIN报文（FIN = 1），序列号为u（seq = u），进入FIN-WAIT 1状态。

客户端B：发送ACK确认报文（ACK = 1），序列号为v（seq = v），确认报文u（ack = u + 1），进入CLOSE-WAIT状态，继续传送数据。

服务端A：收到上述报文进入FIN-WAIT2状态，继续接受B传输的数据。

客户端B：数据传输完毕后，发送FIN报文（FIN = 1，ACK = 1），序列号为w（seq = w），确认报文u（ack = u + 1），进入LAST-ACK状态。

服务端A：发送ACK确认报文（ACK = 1），序列号为u+1（seq = u + 1），确认报文w（ack = w + 1），进入TIME-WAIT状态，等待2MSL（最长报文段寿命），进入CLOSED状态。

客户端B：收到后上述报文后进入CLOSED状态。

4）为什么TCP协议终止链接要四次？

1、当客户端确认发送完数据且知道服务器已经接收完了，想要关闭发送数据口（当然确认信号还是可以发），就会发FIN给服务器。

2、服务器收到客户端发送的FIN，表示收到了，就会发送ACK回复。

3、但这时候服务器可能还在发送数据，没有想要关闭数据口的意思，所以服务器的FIN与ACK不是同时发送的，而是等到服务器数据发送完了，才会发送FIN给客户端。

4、客户端收到服务器发来的FIN，知道服务器的数据也发送完了，回复ACK， 客户端等待2MSL以后，没有收到服务器传来的任何消息，知道服务器已经收到自己的ACK了，客户端就关闭链接，服务器也关闭链接了。

5）2MSL意义：

1、保证最后一次握手报文能到B，能进行超时重传。

2、2MSL后，这次连接的所有报文都会消失，不会影响下一次连接。

大量的TIME_WAIT状态TCP连接,对业务有什么影响?怎么处理?

参考

IP TCP UDP 首部格式

首部介绍，看到面经有问到过
TCP检验以及伪首部介绍

UDP如何实现可靠性传输

参考，可是里边的协议看不太懂哎
个人想法：在应用层模仿TCP可靠传输机制，实现编号以及ack确认，设立缓存区实现重传机制。

TCP模型遇到哪些函数

参考

UDP用到哪些函数

参考

Nagle算法

TCP是基于流的传输协议，在Rlogin和Telnet传输中会出现只有一个字节数据的TCP数据包。而一个TCP数据包的首部加上IP首部就有40个字节，很显然发这样的数据包划不来。为了减少这样的数据包，有人提出了Nagle算法。

Nagle算法简单讲就是，等待服务器应答包到达后，再发送下一个数据包。数据在发送端被缓存，如果缓存到达指定大小就将其发送，或者上一个数据的应答包到达，将缓存区一次性全部发送。

Nagle算法是从发送端角度考虑减少了数据包的个数，时延应答从接收端角度考虑减少了数据包的个数。

什么是TCP粘包？怎么解决这个问题

参考

应用层

HTTP和HTTPS

HTTP: 超文本传输协议，是一个基于请求与响应，无状态的，应用层的协议，常基于TCP/IP协议传输数据，互联网上应用最为广泛的一种网络协议,所有的WWW文件都必须遵守这个标准。设计HTTP的初衷是为了提供一种发布和接收HTML页面的方法。
HTTP报文格式

HTTP通信传输

客户端输入URL回车，DNS解析域名得到服务器的IP地址，服务器在80端口监听客户端请求，端口通过TCP/IP协议（可以通过Socket实现）建立连接。HTTP属于TCP/IP模型中的运用层协议，所以通信的过程其实是对应数据的入栈和出栈。

常见的HTTP 状态代码
HTTP 状态代码
如果向您的服务器发出了某项请求要求显示您网站上的某个网页（例如，当用户通过浏览器访问您的网页或在 Googlebot 抓取该网页时），那么，您的服务器会返回 HTTP 状态代码以响应该请求。

此状态代码提供了有关请求状态的信息，且为 Googlebot 提供了有关您网站和请求的网页的信息。

一些常见的状态代码为：

200 - 服务器成功返回网页
404 - 请求的网页不存在
503 - 服务器暂时不可用
以下提供了 HTTP 状态代码的完整列表。点击链接可了解详细信息。您也可以访问有关 HTTP 状态代码的 W3C 页来了解详细信息。

1xx（临时响应）
用于表示临时响应并需要请求者执行操作才能继续的状态代码。

代码 说明
100（继续） 请求者应当继续提出请求。服务器返回此代码则意味着，服务器已收到了请求的第一部分，现正在等待接收其余部分。
101（切换协议） 请求者已要求服务器切换协议，服务器已确认并准备进行切换。

2xx（成功）

用于表示服务器已成功处理了请求的状态代码。

代码 说明
200（成功） 服务器已成功处理了请求。通常，这表示服务器提供了请求的网页。如果您的 robots.txt 文件显示为此状态，那么，这表示 Googlebot 已成功检索到该文件。
201（已创建） 请求成功且服务器已创建了新的资源。
202（已接受） 服务器已接受了请求，但尚未对其进行处理。
203（非授权信息） 服务器已成功处理了请求，但返回了可能来自另一来源的信息。
204（无内容） 服务器成功处理了请求，但未返回任何内容。
205（重置内容） 服务器成功处理了请求，但未返回任何内容。与 204 响应不同，此响应要求请求者重置文档视图（例如清除表单内容以输入新内容）。
206（部分内容） 服务器成功处理了部分 GET 请求。

3xx（已重定向）
要完成请求，您需要进一步进行操作。通常，这些状态代码是永远重定向的。Google 建议您在每次请求时使用的重定向要少于 5 个。您可以使用网站管理员工具来查看 Googlebot 在抓取您已重定向的网页时是否会遇到问题。诊断下的抓取错误页中列出了 Googlebot 由于重定向错误而无法抓取的网址。

代码 说明
300（多种选择） 服务器根据请求可执行多种操作。服务器可根据请求者 (User agent) 来选择一项操作，或提供操作列表供请求者选择。
301（永久移动） 请求的网页已被永久移动到新位置。服务器返回此响应（作为对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。您应使用此代码通知 Googlebot 某个网页或网站已被永久移动到新位置。
302（临时移动） 服务器目前正从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。此代码与响应 GET 和 HEAD 请求的 301 代码类似，会自动将请求者转到不同的位置。但由于 Googlebot 会继续抓取原有位置并将其编入索引，因此您不应使用此代码来通知 Googlebot 某个页面或网站已被移动。
303（查看其他位置） 当请求者应对不同的位置进行单独的 GET 请求以检索响应时，服务器会返回此代码。对于除 HEAD 请求之外的所有请求，服务器会自动转到其他位置。
304（未修改） 自从上次请求后，请求的网页未被修改过。服务器返回此响应时，不会返回网页内容。

如果网页自请求者上次请求后再也没有更改过，您应当将服务器配置为返回此响应（称为 If-Modified-Since HTTP 标头）。由于服务器可以告诉 Googlebot 自从上次抓取后网页没有更改过，因此可节省带宽和开销。
305（使用代理） 请求者只能使用代理访问请求的网页。如果服务器返回此响应，那么，服务器还会指明请求者应当使用的代理。
307（临时重定向） 服务器目前正从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。此代码与响应 GET 和 HEAD 请求的 301 代码类似，会自动将请求者转到不同的位置。但由于 Googlebot 会继续抓取原有位置并将其编入索引，因此您不应使用此代码来通知 Googlebot 某个页面或网站已被移动。

4xx（请求错误）
这些状态代码表示，请求可能出错，已妨碍了服务器对请求的处理。

代码 说明
400（错误请求） 服务器不理解请求的语法。
401（未授权） 请求要求进行身份验证。登录后，服务器可能会返回对页面的此响应。
403（已禁止） 服务器拒绝请求。如果在 Googlebot 尝试抓取您网站上的有效网页时显示此状态代码（您可在 Google 网站管理员工具中诊断下的网络抓取页面上看到此状态代码），那么，这可能是您的服务器或主机拒绝 Googlebot 对其进行访问。
404（未找到） 服务器找不到请求的网页。例如，如果请求是针对服务器上不存在的网页进行的，那么，服务器通常会返回此代码。

如果您的网站上没有 robots.txt 文件，而您在 Google 网站管理员工具"诊断"标签的 robots.txt 页上发现此状态，那么，这是正确的状态。然而，如果您有 robots.txt 文件而又发现了此状态，那么，这说明您的 robots.txt 文件可能是命名错误或位于错误的位置。（该文件应当位于顶级域名上，且应当名为 robots.txt）。

如果您在 Googlebot 尝试抓取的网址上发现此状态（位于"诊断"标签的 HTTP 错误页上），那么，这表示 Googlebot 所追踪的可能是另一网页中的无效链接（旧链接或输入有误的链接）。

405（方法禁用） 禁用请求中所指定的方法。
406（不接受） 无法使用请求的内容特性来响应请求的网页。
407（需要代理授权） 此状态代码与 401（未授权）类似，但却指定了请求者应当使用代理进行授权。如果服务器返回此响应，那么，服务器还会指明请求者应当使用的代理。
408（请求超时） 服务器等候请求时超时。
409（冲突） 服务器在完成请求时发生冲突。服务器必须包含有关响应中所发生的冲突的信息。服务器在响应与前一个请求相冲突的 PUT 请求时可能会返回此代码，同时会提供两个请求的差异列表。
410（已删除） 如果请求的资源已被永久删除，那么，服务器会返回此响应。该代码与 404（未找到）代码类似，但在资源以前有但现在已经不复存在的情况下，有时会替代 404 代码出现。如果资源已被永久删除，那么，您应当使用 301 代码指定该资源的新位置。
411（需要有效长度） 服务器不会接受包含无效内容长度标头字段的请求。
412（未满足前提条件） 服务器未满足请求者在请求中设置的其中一个前提条件。
413（请求实体过大） 服务器无法处理请求，因为请求实体过大，已超出服务器的处理能力。
414（请求的 URI 过长） 请求的 URI（通常为网址）过长，服务器无法进行处理。
415（不支持的媒体类型） 请求的格式不受请求页面的支持。
416（请求范围不符合要求） 如果请求是针对网页的无效范围进行的，那么，服务器会返回此状态代码。
417（未满足期望值） 服务器未满足"期望"请求标头字段的要求。

5xx（服务器错误）
这些状态代码表示，服务器在尝试处理请求时发生内部错误。这些错误可能是服务器本身的错误，而不是请求出错。

代码 说明
500（服务器内部错误） 服务器遇到错误，无法完成请求。
501（尚未实施） 服务器不具备完成请求的功能。例如，当服务器无法识别请求方法时，服务器可能会返回此代码。
502（错误网关） 服务器作为网关或代理，从上游服务器收到了无效的响应。
503（服务不可用） 目前无法使用服务器（由于超载或进行停机维护）。通常，这只是一种暂时的状态。
504（网关超时） 服务器作为网关或代理，未及时从上游服务器接收请求。
505（HTTP 版本不受支持） 服务器不支持请求中所使用的 HTTP 协议版本。
HTTPS:
《图解HTTP》这本书中曾提过HTTPS是身披SSL外壳的HTTP。HTTPS是一种通过计算机网络进行安全通信的传输协议，经由HTTP进行通信，利用SSL/TLS建立全信道，加密数据包。HTTPS使用的主要目的是提供对网站服务器的身份认证，同时保护交换数据的隐私与完整性。

PS:TLS是传输层加密协议，前身是SSL协议，由网景公司1995年发布，有时候两者不区分。
HTTPS实现原理

1. client向server发送请求https://baidu.com，然后连接到server的443端口，发送的信息主要是随机值1和客户端支持的加密算法
2. server接收到信息之后给予client响应握手信息，包括随机值2和匹配好的协商加密算法，这个加密算法一定是client发送给server加密算法的子集。
3. 随即server给client发送第二个响应报文是数字证书。服务端必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面，这套证书其实就是一对公钥和私钥。传送证书，这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间、服务端的公钥，第三方证书认证机构(CA)的签名，服务端的域名信息等内容。
4. 客户端解析证书，这部分工作是由客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随即值（预主秘钥）。
5. 客户端认证证书通过之后，接下来是通过随机值1、随机值2和预主秘钥组装会话秘钥。然后通过证书的公钥加密会话秘钥。
6. 传送加密信息，这部分传送的是用证书加密后的会话秘钥，目的就是让服务端使用秘钥解密得到随机值1、随机值2和预主秘钥。
7. 服务端解密得到随机值1、随机值2和预主秘钥，然后组装会话秘钥，跟客户端会话秘钥相同。
8. 客户端通过会话秘钥加密一条消息发送给服务端，主要验证服务端是否正常接受客户端加密的消息。
9. 同样服务端也会通过会话秘钥加密一条消息回传给客户端，如果客户端能够正常接受的话表明SSL层连接建立完成了。

HTTP协议和HTTPS协议区别如下：
1）HTTP协议是以明文的方式在网络中传输数据，而HTTPS协议传输的数据则是经过TLS加密后的，HTTPS具有更高的安全性

2）HTTPS在TCP三次握手阶段之后，还需要进行SSL 的handshake，协商加密使用的对称加密密钥

3）HTTPS协议需要服务端申请证书，浏览器端安装对应的根证书

4）HTTP协议端口是80，HTTPS协议端口是443

HTTPS优点：

HTTPS传输数据过程中使用密钥进行加密，所以安全性更高

HTTPS协议可以认证用户和服务器，确保数据发送到正确的用户和服务器

HTTPS缺点：

HTTPS握手阶段延时较高：由于在进行HTTP会话之前还需要进行SSL握手，因此HTTPS协议握手阶段延时增加

HTTPS部署成本高：一方面HTTPS协议需要使用证书来验证自身的安全性，所以需要购买CA证书；另一方面由于采用HTTPS协议需要进行加解密的计算，占用CPU资源较多，需要的服务器配置或数目高
————————————————
参考

get和post的区别

参考
本质上并无太大区别，只不过由于http的规定和浏览器的一些限制使得他们表现出一些不同。
最重要的不同；

• 对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。

其他区别：
GET在浏览器回退时是无害的，而POST会再次提交请求。

GET产生的URL地址可以被Bookmark，而POST不可以。

GET请求会被浏览器主动cache，而POST不会，除非手动设置。

GET请求只能进行url编码，而POST支持多种编码方式。

GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。

GET请求在URL中传送的参数是有长度限制的，而POST么有。

对参数的数据类型，GET只接受ASCII字符，而POST没有限制。

GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。

GET参数通过URL传递，POST放在Request body中。

短连接长连接

参考

http2.0 1.0区别

HTTP 2.0与HTTP 1.1区别
1.0和1.1区别

cookie session以及token

• session存储于服务器，可以理解为一个状态列表，拥有一个唯一识别符号sessionId，通常存放于cookie中。服务器收到cookie后解析出sessionId，再去session列表中查找，才能找到相应session。依赖cookie
• cookie类似一个令牌，装有sessionId，存储在客户端，浏览器通常会自动添加。
• token也类似一个令牌，无状态，用户信息都被加密到token中，服务器收到token后解密就可知道是哪个用户。需要开发者手动添加。
• jwt只是一个跨域认证的方案

参考

Socket 网络编程

IO模型

Linux IO模式及 select、poll、epoll详解

微信公众号的文章
码上
个人觉得解决阻塞问题，采取的就是一种轮询的方式吧，这个socket没有事件发生就去轮询查看其他的事件。
接下来参考于b站
select

poll
通过使用pollfd数组，解决了select的①②两个缺陷

epoll
这里讲的是用户态和内核共享epfd，我觉得还有待求证。。。

总结：select poll 需要每次把所有用户态的文件事件复制到内核空间处理，轮询完一遍后把把所有的fd复制到用户空间，epoll是内核空间用一个红黑树维护所有的fd，只把就绪的fd用链表复制到用户空间

linux下非阻塞io库 epoll

这个重点看一下，讲的很好

• LT 模式下，读事件触发后，可以按需收取想要的字节数，不用把本次接收到的数据收取干净（即不用循环到 recv 或者 read 函数返回 -1，错误码为 EWOULDBLOCK 或 EAGAIN）；ET 模式下，读事件必须把数据收取干净，因为你不一定有下一次机会再收取数据了，即使有机会，也可能存在上次没读完的数据没有及时处理，造成客户端响应延迟。
• LT 模式下，不需要写事件一定要及时移除，避免不必要的触发，浪费 CPU 资源；ET 模式下，写事件触发后，如果还需要下一次的写事件触发来驱动任务（例如发上次剩余的数据），你需要继续注册一次检测可写事件。
• LT 模式和 ET 模式各有优缺点，无所谓孰优孰劣。使用 LT 模式，我们可以自由决定每次收取多少字节（对于普通 socket）或何时接收连接（对于侦听 socket），但是可能会导致多次触发；使用 ET 模式，我们必须每次都要将数据收完（对于普通 socket）或必须理解调用 accept 接收连接（对于侦听socket），其优点是触发次数少。