哈喽哈喽，这里是小菜不拖延博主，由于博主最近打算找实习了，无奈计算机网络知识实在匮乏，只能连夜恶补（留下悔恨的泪水），如果你也想突击突击，希望能帮到你
本篇文章基于博主阅读别人的文章总结的，那和别人的文章有什么不一样嘞，知识点不会一块一块的，更是连锁的，就更像面试官夺命连环问啦
什么是TCP/IP
- 传输控制协议/网际协议，不是两个协议，而是一簇协议，是一种属于传输层的网络协议，
三次握手
客户端向服务器发送了一个syn数据包，在TCP头部的标志位中将syn标志为1，表示请求连接
服务器收到syn包之后，会发送一个（syn=1,ack=1）的确认应答数据包， 表示对客户端的syn进行确认
客户端收到服务器应答之后，发送一个ack包，对服务器的syn进行确认 经过三次握手就可以成功建立连接，准备好传输数据
为什么不是两次握手
- 首先我们要明确三次握手的目的是什么，是客户端和服务端双方要相互确认和写上一些参数（比如报文长度等），因为没有第三次握手的确认双方的序列号是没有办法同步的，简单来理解就是，客户端发送自己的信息给服务端，服务端返回给客户端自己受到的信息是否正确并且告诉了客户端自己的信息，此时，双方能够确认是的客户端的信息，经过第三次，客户端返回给服务端，确认自己收到的服务端的信息，这样双方的信息才是都经过确认的。
- 而且会有其他的问题，假如只有两次握手，客户端发送一个请求得到报文段，但是它穿得比较慢，引起了超时重传，重传的报文段被服务端接受了，此时服务端返回确认报文段并且进入连接建立状态，传输完成之后，双方关闭连接，此时刚才传得慢的的报文段到达了服务端，服务端又建立连接，向客户端发送报文段，但是由于客户端是明确自己没有发送请求连接的，所以他不会理会这一报文段，处于关闭状态，不会发送数据，而服务端一直开启连接等待就造成了资源的浪费
那他为什么可靠/怎么保证可靠的
确保数据可靠就是不漏不重且有顺序
- 不重 应答机制：tcp/ip存在应答机制，发送数据每个数据包都会得到回应，如果没有得到回应，那就告诉我们应该是丢包了，它会发送一个确认应答包给发送方，告诉它已经收到了这个数据包。同时，确认应答包中也包含一个序号，表示接收方期望下一个收到的数据包的序号是多少。
- 不漏 :超时重传：发出数据之后会启动一个定时器，可能因为丢包等原因，没有得到回应，等待时间如果过长超时，那么我们就重新传输该数据包 -流量控制、拥塞控制：当接收方来不及处理发送方的消息的时候可以降低 对方的发送速率，防止包丢失。慢开始（由小到大增加到拥塞窗口的数据）
四次挥手
由于tcp是全双工的（就是双方可以同时收发数据），所以需要双方确认都关闭链接
- 客户端发送标志位是fin的报文段，设置序列号，然后进入fin_wait_1的状态表示没有数据发送了
- 服务端收到该报文段，返回一个标志位为ack的报文段，设置序列号+1，客服端进入fin_wait_2，服务端确认客户端的关闭请求
- 服务端发送标志位为fin的报文段，请求关闭链接，服务端进入last_ack阶段
- 客户端接收到后，向服务端发送标志位为ack的报文段，客户端进入time_wait阶段，服务端接收到之后就关闭连接，客户端2msl没接收到回复，就证明服务端已经关闭了，那客户端也可以关闭连接了。
为什么是四次
客户端发送fin，仅代表客户端不再发送消息但是接受消息，服务端回应客户端的消息，并发送ack包应答，服务端可以发完ack还有数据需要发送，等到没有数据发送，在发送fin报文，表示服务端同意关闭。
为什么要等待2mls
因为，如果我们不等待直接关闭的话，如果报文段丢失，那么服务器没有收到信息就会进行超时重传，但是此时我们的客户端已经处于关闭状态，那么就会造成服务端不断超时重传并且无法关闭的情况。mls是报文存在的最长生存时间，等到两倍可保证报文段在网络中完全消失
https四次握手，随机数生成，证书生成
这里的四次握手时tls的四次握手，注意区分http请求过程当中的tcp三次握手和tls四次握手
tls四次握手
- 客户端支持版本协议、随机数、支持的密码套件列表
- 确定的版本协议、服务器的随机数、选定的密码套件、服务器的证书
- 客户端验证证书合法性、生成随机数并使用证书公钥加密发送
- 服务端使用私钥解密 最后双方根据确定的加密方法，使用前面的三个随机数生成对话密钥，来加密整个对话过程
tcp和UDP的区别
tcp是面向连接协议，提供可靠服务就是说通过tcp连接数据不回丢失、重复并且是按照顺序的，UDP是无连接协议，是不具有可靠性的，就是说他没有办法保证数据不会丢失、重复、按照顺序。而且tcp的头开销大，可以到60字节，而udp8字节就很大了
我觉得这个过程特别像打电话和寄信，打电话我们两个是面对面交流的，我能够保证你已经听到我说话了，并且我对你说的话就是我想说的，但是UDP就比较像寄信，我不知道你收到我的信息没有，也不知道你收到的顺序对不对，就比如我想跟你说的是“算了/我们明早八点/在公园见“,UDP传输可能就会变成”我们明早八点/在公园见/算了”本意是想见面，然后传输变成不见面了
tcp粘包和拆包
粘包：
- 发送方发送的若干数据包到接收方时粘成一个包(注意tcp是面向字节流，是没有界限的数据，本身是没有包的概念的，只是为了好理解现象这么说)
- 可能发生在数据链路层、网络层、传输层
tcp为什么存在粘包:
tcp是基于字节流的没有明确的边界区分数据包，发送方和接收方都有缓冲区，用于暂存数据，若数据字节大小小于这个缓冲区，发送方可能会将多个数据块合成一个tcp报文进行发送，也就是粘包；但是如果大于，数据块拆分成多个tcp报文段进行发送，就可能发生拆包。同样的，对于接收方来说如果读取字节小，那么就会拆包。
UDP为什么没有粘包: 因为udp当中，udp协议是将应用层传递给它的数据封装成包，直接发出去，接收端也是按照包的边界来接受的，所以udp并不会对数据进行拆分
解决方法
- 消息定长：固定报文的字节大小，如果小于就补充空格
- 在包围添加特殊字符进行分割：比如用回车等来进行结尾，接收方接收到该字符就认为收到了完整的数据包，没收到就继续接受（那么这里就会又涉及到一个问题，假如数据当中存在特殊字符提前结束数据怎么办？那么第一个解决办法就是添加转义字符，第二个方法就是在应用层协议当中我们去添加数据长度这个字段）
http和https的区别
- HTTP是明文传输协议，数据在传输过程中不会进行加密
- HTTPS使用安全套接层协议（SSL/TLS）对传输的数据进行加密
get和post请求
post、get都是网络请求的方式，底层都是tcp/ip协议，不同的是，get请求参数存放在url路径当中，post参数放在body当中，由于url有限制（请求数据长度一般在1k以下），这也导致get方法的参数是有限的，一般业务上的参数都是很多的，所以我们一般多个参数时都会采用post请求。get请求会产生一个tcp的包，会把请求头和数据一并发出去，post有两tcp的包，会先发送header，服务器响应100，再继续发送data。由于get请求会将参数显示的放在url中，而且get可以被缓存也会存在一些安全隐患。
http状态码
- 信息响应100-199
- 成功响应200-299
- 重定向消息300-399
- 客户端错误400-400
- 服务端错误500-599
300
- 301:所请求资源被永久移动到一个新的地址
- 302：所请求资源被暂时移动到一个新的地址
400
- 400:错误的请求语法等
- 401： 客户端必须进行身份验证，比如用户没有登陆、或者token过期了
- 403： 没有访问权限，比如ip被列入黑名单（写爬虫过多访问一个网站的时候就经常被网站的反扒禁止访问）
- 404：输入错误，找不到地址
- 405：输入地址正确，但是使用了不正确的http方法，比如需要get但是接收到的是post请求
500
- 500:服务器不知怎么处理
- 501：服务器不支持的请求方法，比如http协议版本、不支持的自定义请求方法等
如何理解HTTP协议是无状态的
因为每个请求都是独立的，请求包含了处理这个请求所需的完整的数据，浏览器发送数据给服务器，服务器响应，当浏览器继续发送请求的时候，服务器并不会知道你刚才请求过，也就是说服务器是不会记住你是谁的
cookie
是一种在客户端和服务器之间交换的小型文本，存储在客户端，会存储用户的一些信息。简单来说就是让http从无状态变成有状态，让服务器从不认识你到认识你，经常我们浏览网页都会问我们是否接受所有cookie，因为拥有cookie就可以知道我们平时上网的一些习惯，所以这里涉及到一些隐私，所以他也会询问你是否接受
session
储存在服务端，服务器创建一个唯一的二sessionid，发送给客户端浏览器，通常以cookie形式存储到客户端
区别:
- 存储位置
- 数据安全:由于cookie在客户端、session在服务端，所以cookie容易被篡改
- 容量：cookie容量小一般在4kb左右，session没有容量限制
- 开销：cookie存储在客户端，每次请求会携带cookie增加网络传输开销，但是session在服务端，只需传输seesionid即可
HTTP长连接和短连接？
- 短连接:每一次请求都需要建立一个新的tcp请求。就是客户端发送请求，服务端响应完成之后就会关闭连接
- 长连接:服务器于客户端之间的连接在一个请求之后保持打开状态，可以被多个请求复用
- 好处：减少建立链接和关闭的开销、提高响应请求响应的频率
- 坏处：长时间占用服务器资源如果长时间没有活动就比较浪费资源、必须双方都支持长连接
什么是数字证书？
- 一种用于验证网络通信中身份和信息安全的电子凭证
内容
- 证书持有者的名称和公钥
- 有效期和颁发机构
- 数字签名
有效检查
- 1. 检查证书的签名: 每个数字证书都是由一个证书颁发机构（CA）签名的。验证过程包括：使用 CA 的公钥来验证证书的签名。如果签名有效，说明证书没有被篡改。
- 2. 验证证书链: 确保证书是由受信任的 CA 颁发的，通常包括：检查证书的颁发者（Issuer）是否在受信任的根证书列表中。逐级验证每个中间证书，直到到达根证书。
- 3. 检查证书的有效期: 证书都有一个有效期，包括开始日期和到期日期。需要确认：当前日期在有效期范围内。
- 4. 检查证书吊销状态: CRL（证书吊销列表） ：下载并检查证书是否在 CA 提供的吊销列表中。OCSP（在线证书状态协议） ：向 OCSP 服务器查询证书的状态。
- 5. 检查证书的主题: 确保证书的主题（Subject）与实际使用者匹配。这可以确保：证书是针对正确的域名或实体。
//例如node
const crypto = require('crypto');
const fs = require('fs');
// 加载证书和CA公钥
const cert = fs.readFileSync('certificate.pem');
const caCert = fs.readFileSync('ca_certificate.pem');
// 创建一个 X.509 证书对象
const certificate = crypto.createVerify('SHA256');
certificate.update(cert);
// 验证签名
const isVerified = certificate.verify(caCert, 'signature');
console.log(`证书合法性验证结果: ${isVerified}`);
验证过程
- 服务器向浏览器发送数字证书
- 浏览器验证证书合法性（是否过期）
- 验证通过，浏览器生成随机对称密钥，用服务器的公钥加密之后发送给服务器
- 服务器解密数据，再用对称密钥加密响应数据发送给浏览器
- 浏览器使用对称密钥解密显示数据
WebSocket与socket的区别
- Websocket是应用层协议，建立在http之上，是一种长连接，允许进行全双工通信
- Socket是传输层协议，用于不同主机之间建立连接，根据需求收发数据，没有保持连接的特性
什么是DoS、DDoS、DRDoS攻击？
- Dos攻击：向服务器发送大量无效请求，耗尽资源
- DDos攻击：利用多个主机同时向目标服务器发起攻击
- DRDos攻击: 一种特殊的DDos工具，利用有漏洞的服务器作为反射器，向目标服务器发送大量伪造请求，是服务器浏览增加导致服务不可用
什么是CSRF攻击，如何避免
- 利用用户已登录的身份来执行非法操作，，攻击者欺骗用户点击恶意链接，从而实现攻击目的
措施：
- 使用验证码：在一些关键操作比如修改密码删除数据的时候，使用验证码，确保是人类进行操作而不是自动化脚本
- 添加CSRFtoken：服务器随机生成token并将其存储在用户会话中，在生成的表单当中添加一个隐藏字段将token嵌入，随着表单token一起发送给服务器，由于token是随机生成的，所以攻击者无法猜测token的正确值，从而无法伪造请求
