计算机网络

计网

1.网络协议

2.三次握手

第一次：客户端发送初始序号x和syn=1请求标志

• 第二次：服务器发送请求标志syn，发送确认标志ACK，发送自己的序号seq=y，发送客户端的确认序号ack=x+1

• 第三次：客户端发送ACK确认号，发送自己的序号seq=x+1，发送对方的确认号ack=y+1

为什么不是两次


为什么不是四次

3.TCP UDP区别

4.TCP为什么可靠

ACK和超时重发机制
TCP首先会按照顺序给发送的数据标上号码。TCP每发送一个数据报，都会期待一个接收端ACK的回复，就知道接收端已经收到消息了。如果短时间内没有收到ACK，那么TCP就会对消息进行自动重发。

未收到ACK就说明消息一定就丢了吗？
有可能接收端收到消息了，返回ACK的途中发生了丢失。这个时候这个时候依然会进行超时重发。接收端可能会收到同样的消息，但是对发送的数据进行编号了，如果接收端收到重复消息直接丢失就可以了。

滑动窗口

拥塞控制： 慢启动，拥塞避免，快重传，快恢复
慢开始：由小到大的增加拥塞窗口的大小
拥塞避免：让拥塞窗口缓慢增大，每经过一个往返时间就把发送方的拥塞窗口+1而不是加倍
快重传：收到一个失序的报文段就立即发出重复确认，而不是等到自己发送数据时再捎带确认
快恢复：当发送方收到三个连续的重复确认的时候，就把窗口减半，防止发生拥堵（但不执行慢开始）

5.三次握手阶段，最后一次ACK包丢失会发生什么

服务端：
TCP连接状态改变，改为SYN_RECV，并且根据TCP的超时重传机制，等待一段时间后重新发送SYN+ACK，让客户端收到后重新发送ACK，如果重发一定次数后，还没收到客户端的ACK，一段时间后服务端自动关闭这个连接

客户端：
客户端认为已经建立连接了，如果客户端向服务端发送数据，服务端会回发一个RST包响应（Reset,表示复位，用于异常的关闭连接），然后客户端就知道第三次握手失败了

6.四次挥手

第一次挥手： 客户端向服务端发送释放连接报文（FIN=1,ACK=1），主动关闭连接，同时等待服务端的确认

第二次挥手： 服务端收到后，回发一个确认报文（ACK=1）（序列号为k，确认号+1）
这时TCP连接处于半关闭状态，客户端到服务端的连接已经释放了，但是服务端到客户端的连接还没释放，客户端已经没有要发送的数据了，但是服务端可能还有要发的

第三次挥手： 服务端向客户端发送释放连接报文（FIN=1 ACK=1），主动关闭连接，同时等待客户端的确认

第四次挥手： 客户端收到服务端的连接释放报文后，立即发出确认报文（ACK=1），（序列号seq=u+1，确认号ack=w+1）
这个时候客户端进入了time_wait状态，此时客户端到TCP的连接还没有释放，必须经过2MSL时间后，才会进入关闭状态。服务端收到客户端发的确认就立即进入关闭状态，服务端结束TCP连接的时间要比客户端早点

第二次和第三次挥手是否可以合并
不需要传输数据的话就可以合并

7.为什么建立连接是三次握手，而关闭连接却是四次挥手呢？

服务器收到客户端的FIN后，可能还有一些数据要传输，所以不能立刻关闭，但还会做出应答，返回ACK确认。服务端接下来可能会继续发送数据，数据发送完之后，服务器会向客户端发送FIN，表示数据已经发完了，请求关闭连接。服务端的ACK和FIN一般会分别发送，所以多了一次。

8.TIME_WAIT

1.确保ACK报文能到达服务端，使服务端正常关闭连接
第四次挥手时，客户端第四次挥手的ACK报文不一定到达服务端，服务端会超时重传FIN,ACK报文，如果这个时候客户端断开连接了，那就没法响应第二次请求了，服务端收不到ACK回应，就无法正常的断开连接

（2MSL：客户端ACK报文1MSL超时+服务端FIN报文1MSL传输，客户端等待2MSL就能收到服务端重传的FIN，ACK报文，然后客户端重发一次ACK，并且启动2MSL计时器，保证服务端正常关闭）

2.防止已经失效的连接请求报文段出现在之后的连接中
TCP要求在2MSL之内不使用相同的序列号，客户端发完最后一个ACK之后，在过2MSL，就可以保证本连接持续的时间内产生的所有报文段都从网络中消失，这样就可以使下一个连接中不会出现这种旧的连接请求报文段，或者受到这种请求报文段也不处理。

9.如果已经建立了连接，但是客户端出现了故障怎么办

通过定时器+超时重传机制，尝试获取确认，直到最后断开连接
TCP设有一个保活计时器，服务端每收到一次客户端的数据，都会重新复位这个计时器，这段时间内没收到客户端的请求，服务器就开始重试，每隔一段时间就发一次，一连发送10个探测报文客户端还没反应，服务端就认为连接断开了。

10.TIME_WAIT过多会导致什么

服务端：消耗服务器资源
客户端：TIME_WAIT过多，就会导致端口资源被占用，因为端口就65536个，占满就不能创建新的连接了

解决：
net.ipv4.tcp_tw_recycle=1 开启TCP连接中的TIME_WAIT sockets快速回收，默认0关闭

11.TIME_WAIT是服务端的状态还是客户端的状态

12.CLOSE_WAIT

出现大量close_wait的现象，主要原因是某种情况下对方关闭了socket链接，但是我方忙与读或者写，没有关闭连接。

解决：
检测出对方已经关闭的socket，然后关闭它。
给每一个socket设置一个时间戳last_update，每接收或者是发送成功数据，就用当前时间更新这个时间戳。定期检查所有的时间戳，如果时间戳与当前时间差值超过一定的阈值，就关闭这个socket。

13.HTTP

14.HTTP和HTTPS区别

15.HTTPS加密过程

1. 客户端发起请求

2. 服务端配置公钥私钥。如果是使用购买的证书，把公钥告诉客户端。

3. 服务端把当前此次请求的证书（公钥）传送过来

4. 客户端进行证书解析

客户端会验证公钥是否有效。如果没有问题，就回生成一个随机值，并对其进行加密，（这个随机值其实就是对称加密的私钥）

5. 将加密后的随机值等加密信息传给服务端

6.服务端解密信息

服务端用私钥解密后，得到了客户端传过来的随机值（私钥），然后把内容进行对称加密。

7. 通信。因为客户端跟服务端都有对称加密的秘钥。所以ok了。

加密过程中的对称加密非对称加密

首先用的是非对称加密。把公钥给客户端，私钥在服务端。客户端用公钥验证通过后，会生成私钥进行对称加密。然后传给后台。

为什么这么做呢。

对称加密与解密使用的是同样的密钥，所以速度快，但由于需要将密钥在网络传输，所以安全性不高。
非对称加密使用了一对密钥，公钥与私钥，所以安全性高，但加密与解密速度慢。
所以第一次用公钥私钥验证。没问题之后，在用对称加密。这样既安全又高效。

16.对称加密和非对称加密

17.HTTP1.1和HTTP2.0区别

1、新的传输格式：2.0使用二进制格式，1.1依然使用基于文本格式
2、多路复用：连接共享，不同的request可以使用同一个连接传输（最后根据每个request上的id号组合成正常的请求）
3、header压缩：由于1.1中header带有大量的信息，并且得重复传输，2.0减少了需要传输的hearder大小（encoder），让通讯双方都缓存一份头文件的表，避免重复的header传输
4、服务端推送：服务端除了响应最初的请求之外，还可以额外向客户端推送资源

18.http1.0和http1.1的主要区别：

1、缓存处理：1.1添加更多的缓存控制策略（如：Entity tag，If-Match）
2、网络连接的优化：1.0有浪费带宽的情况，例如客户端只是想要某个对象的一部分，服务端就把整个对象都发过来了，不支持断点续传功能，1.1允许只请求资源的某个部分
3、错误状态码的增多：1.1新增了24个错误状态响应码，更加明确各个状态
4、Host头处理： 支持Host头域，不在以IP为请求方标志
5、长连接： 1.0短连接，1.1长连接，减少了建立和关闭连接的消耗和延迟。

19.HTTP长连接和短连接

http1.0用的是短连接，每进行一次http操作就建立一次连接，任务结束就断开

http1.1用的长连接，会在响应头中加入 connection：keep-alive
使用长连接，当一个网页打开后，客户端和服务端之间用于传输http数据的tcp连接不会关闭，客户端再访问这个服务器的网页，会使用这条已经建立的连接，不是永久保持连接，是持续一段时间

20.HTTP请求报文和响应报文的格式

请求报文：
请求行、请求头部、空行和请求数据

响应报文：
状态行，响应首部，空行，响应数据

21.GET和POST区别

post：传输数据主体
get：获取资源

2.get使用URL或者cookie传参，post是把数据放到body里（http协议用法规定的）

3.get方式提交的数据有长度限制，post的数据可以很大

4.post比get安全，因为数据在地址栏上不可见

5.get请求是幂等性的，post不是，幂等性是对同一个URL的多个请求应该返回同样的结果

22.HTTP常用的请求方式

23.输入一个URL

1.DNS解析
输入一个网址并按回车之后浏览器会根据输入的URL查找对应的IP。

浏览器DNS缓存->操作系统DNS缓存->操作系统本地host文件->操作系统向本地域名服务器发起请求查找本地DNS缓存->操作系统向根域名服务器发起请求得到顶级域名服务器的IP

2. TCP连接
浏览器得到IP后，向服务器发送TCP连接。TCP三次握手目前HTTP协议大多都是1.1，在1.1的协议里，默认开启了keep-alive，这样建立的TCP连接，可以在多次请求中复用，不需要重新连接。

3.浏览器发送HTTP请求
浏览器和服务器建立连接以后，浏览器会给这个IP地址的服务器发送一个http请求。

通过 TCP 套接字，客户端向 Web 服务器发送一个文本的请求报文，一个请求报文由请求行、请求头部、空行和请求数据 4 部分组成。

（1）请求行
由请求方法字段、URL字段和HTTP协议版本字段3个字段组成，它们用空格分隔。例如，GET /index.html HTTP/1.1。
HTTP协议的请求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。

（2）请求头部
由关键字/值对组成，每行一对，关键字和值用英文冒号“:”分隔。请求头部通知服务器有关于客户端请求的信息，典型的请求头有：

User-Agent：产生请求的浏览器类型。

Accept：客户端可识别的内容类型列表。

Host：请求的主机名，允许多个域名同处一个IP地址，即虚拟主机。

（3）空行
最后一个请求头之后是一个空行，发送回车符和换行符，通知服务器以下不再有请求头。

（4）请求数据
username=peiyuan&password=123

4.服务器处理请求
服务器收到浏览器的请求以后，会解析这个请求（读请求头），然后生成一个响应头和具体响应内容。接着服务器会传回来一个响应头和一个响应，响应头告诉了浏览器一些必要的信息，例如重要的Status Code，2开头如200表示一切正常，3开头表示重定向，4开头是客户端错误，如404表示请求的资源不存在，5开头表示服务器端错误。响应就是浏览器请求的页面内容。

Web 服务器解析请求，定位请求资源。服务器将资源复本写到 TCP 套接字，由客户端 读取。一个响应由状态行、响应头部、空行和响应数据 4 部分组成。

5.浏览器解析渲染页面

6…释放连接 TCP 连接
若 connection 模式为 close，则服务器主动关闭 TCP 连接，客户端被动关闭连接， 释放 TCP 连接;若 connection 模式为 keepalive，则该连接会保持一段时间，在该时间内 可以继续接收请求;

24.HTTP1.1及优化

25.SQL注入

SQL注入即是指web应用程序对用户输入数据的合法性没有判断，攻击者可以在web应用程序中事先定义好的查询语句的结尾上添加额外的SQL语句，这样就会欺骗数据库服务器执行非授权的任意查询，从而得到相应的数据信息。

解决方案：
1.使用参数化语句，不要拼接sql
不让用户的输入嵌入到SQL语句中。而是通过参数来传递这个变量，这样就可以有效的防治SQL注入式攻击。

2.加强对用户输入的验证。
在SQLServer数据库中，有比较多的用户输入内容验证工具，可以帮助管理员来对付SQL注入式攻击。测试字符串变量的内容，只接受所需的值。拒绝包含二进制数据、转义序列和注释字符的输入内容。这有助于防止脚本注入，防止某些缓冲区溢出攻击。测试用户输入内容的大小和数据类型，强制执行适当的限制与转换。这即有助于防止有意造成的缓冲区溢出，对于防治注入式攻击有比较明显的效果。

3.尽量使用SQL Server数据库自带的安全参数。

4. 普通用户与系统管理员用户的权限要有严格的区分。

26.SYN攻击

SYN攻击就是伪造大量不存在的IP地址，并向Server不断发送SYN包，导致正常的SYN请求因为队列满了而被丢弃，会造成网络拥塞，系统瘫痪。

解决：
降低SYN timeout时间，使得主机尽快释放半连接的占用或者采用SYN cookie设置，如果短时间内收到了某个IP的重复SYN请求，我们就认为受到了攻击。或者采用防火墙设置等外部网络也可以进行拦截。

27.DOS DDOS

DOS攻击（拒绝服务）的原理：
首先攻击者向被攻击的服务器发送大量的虚假IP请求，被攻击者在收到请求后返回确认信息，等待攻击者进行确认，该过程需要TCP的三次握手，由于攻击者发送的请求信息是虚假的，所以服务器接收不到返回的确认信息，在一段时间内服务器会处与等待状态，当被攻击者等待一定的时间后，会因连接超时而断开，这时攻击者在次发送新的虚假信息请求，这样最终服务器资源被耗尽，直到瘫痪。

DDOS（分布式拒绝服务）：
这个的攻击借助于客户/服务器技术，将多个计算机联合起来作为一个攻击平台，对一个或者是多个目标发动攻击，从而成倍的提高就裁决服务攻击的威力。

解决：
主要靠平时维护和扫描来对抗。比如说添加防火墙规则、加大带宽、增加服务器；还可以用Nginx防范（限制每秒请求数，限制IP连接数）

28.http请求体由什么组成

请求方法，URL，http版本号

29.一次完整的HTTP请求所经历的7个步骤

1. 建立TCP连接

在HTTP工作开始之前，Web浏览器首先要通过网络与Web服务器建立连接

2. Web浏览器向Web服务器发送请求命令

一旦建立了TCP连接，Web浏览器就会向Web服务器发送请求命令。例如：GET/sample/hello.jsp HTTP/1.1。

3. Web浏览器发送请求头信息

浏览器发送其请求命令之后，还要以头信息的形式向Web服务器发送一些别的信息，之后浏览器发送了一空白行来通知服务器，它已经结束了该头信息的发送。

4. Web服务器应答

客户机向服务器发出请求后，服务器会客户机回送应答， HTTP/1.1 200 OK ，应答的第一部分是协议的版本号和应答状态码。

5. Web服务器发送应答头信息

正如客户端会随同请求发送关于自身的信息一样，服务器也会随同应答向用户发送关于它自己的数据及被请求的文档。

6. Web服务器向浏览器发送数据

Web服务器向浏览器发送头信息后，它会发送一个空白行来表示头信息的发送到此为结束，接着，它就以Content-Type应答头信息所描述的格式发送用户所请求的实际数据。

7. Web服务器关闭TCP连接

一般情况下，一旦Web服务器向浏览器发送了请求数据，它就要关闭TCP连接，然后如果浏览器或者服务器在其头信息加入了这行代码：

Connection:keep-alive

TCP连接在发送后将仍然保持打开状态，于是，浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间，还节约了网络带宽。

30.cookie session token jwt

HTTP协议本身是无状态的,服务器无法判断用户的身份，不可能每次用户来了都去数据库里拿一下username和password。所以客户第一次向服务器发送请求，服务器端收到后校验用户名和密码，校验正确就会在服务器端存储一个sessionId和session的映射关系,session里面存的就是用户的信息，服务端给用户响应的时候会把sessionId以set-cookie的方式种在客户端，这个用户下次再访问的时候，服务端通过cookie中的sessionId找到对应的session，来判断用户。

session：
session代表客户端和服务端一次会话的过程，session存储用户的一些属性和信息，当用户切换web页的时候，存在session里的信息不会丢失，当客户端关闭或者session超时失效会话才会结束。

cookie机制：(用户第一次访问并登陆一个网站)
1.客户端发送一个请求到服务器
2.服务器发送一个HttpResponse响应到客户端，其中包含Set-Cookie的头部
3.客户端保存cookie，之后向服务器发送请求时，HttpRequest请求中会包含一个Cookie的头部
4.服务器返回响应数据

token:
服务器存了太多了session，性能可能受到影响，session复制和粘性session的方法也不能完全解决这个问题，当用户登录的时候，服务器给用户下发一个token，并且加上一个只有服务器才知道的密钥，这个token里面就存储了用户的信息，下次用户请求的时候，对这个密钥解析，用CPU计算时间来换取session的存储空间（token不需要去考虑用户在哪一台服务器登录）

这个token必须要在每次请求时传递给服务端，它应该保存在请求头里， 另外，服务端要支持CORS(跨来源资源共享)策略，一般我们在服务端这么做就可以了Access-Control-Allow-Origin: *。

31.cookie和session是怎么配合的


32.负载均衡算法

33.状态码

100 客户端继续请求， http1.1里post先发送header，获得100则继续发送body，获得401要求客户端进行HTTP需要认证，所以不用继续了，节省了带宽。
http1.1还支持获得服务端对象的部分资源，是通过http请求头里的range头域实现的，返回206则代表了获取部分get请求。
200请求成功，201请求成功并在服务器端创建了新资源。
202请求被接受了，但是请求没有处理结束。
206代表实现了部分get请求。
300 代表请求的资源有多种类型。
301代表请求的资源被永远移到了其他地方，reponse body里的location URL里指明了资源现在的位置。
302重定向，临时转移到其他地方。
304表示get请求不可用。
400请求有语法错误。
404请求的url错误，请求的资源不存在。
403请求被接收了，但是被拒绝服务。
405表示请求的方法不允许执行。
407表示客户端需要认证。
414表示请求的URL过长。
500服务器内部有错误。
503服务器暂时不提供http服务。