资源参考：沉默王二、小林coding
OSI模型和TCP/IP模型介绍一下，五层模型又是什么？
OSI 是理论上的网络通信模型，TCP/IP 是实际应用层面上的网络通信模型
OSI模型包括7层：
应用层：负责给应用程序提供统一的接口
表示层：负责数据格式转换
会话层：维护通信会话
传输层：负责端到端的传输
网络层：负责主机到主机的传输
数据链路层：进行数据的封装、寻址
物理层：在物理链路中进行传输
TCP/IP模型包括四层：
应用层 ：支持HTTP、DNS（SMTP、FTP）等协议，为用户提供应用功能
传输层：负责端到端的传输（TCP、UDP协议）
网际层：实现主机到主机的传输，依靠于IP协议
网络接口层：将数据封装成帧发送到网络上
OSI 是理论上的网络通信模型，TCP/IP 是实际应用层面上的网络通信模型 ，五层结构是为了方便理解和教学
五层结构把四层结构的网络接口层拆为数据链路层和物理层
数据链路层：确保从一个节点到另一个节点的可靠传输，会将数据封装成帧。交换机、网桥是数据链路层设备。
物理层：实际传输经过的设备，比如电缆、光纤等。
地址栏输入url到显示网页的过程了解吗？
解析url：分析 URL 所需要使用的传输协议和请求的资源路径
缓存判断：会去浏览器缓存和系统缓存里判断是否存在对应的ip地址
DNS 解析：如果不存在，浏览器会发起一个 DNS 请求到本地 DNS 服务器，将域名解析为服务器的 IP 地址，如果本地DNS服务器没有则回去根、顶级、权威域名服务器去查。（DNS协议）
TCP 连接：接着浏览器会通过解析得到的 IP 地址与服务器建立 TCP 连接。这一步涉及到 TCP 的三次握手，用于确保双方都已经准备好进行数据传输了。（TCP协议、IP协议、ospf协议、arp协议）
发送 HTTP 请求：浏览器构建 HTTP 请求，包括请求行、请求头和请求体；然后将请求发送到服务器。（HTTP协议）
服务器处理请求：服务器接收到 HTTP 请求后，根据请求的资源路径，经过后端处理，生成 HTTP 响应消息；响应消息包括状态行、响应头和响应体。
浏览器接收 HTTP 响应：浏览器接收到服务器返回的 HTTP 响应数据后，开始解析响应体中的 HTML 内容，最终渲染页面。
断开连接：最后进行TCP 四次挥手，连接结束。
常见的端口及服务
HTTP:80
DNS:53
HTTPS:443
Mysql：3306
HTTP的常见的状态码
HTTP 状态码分为 5 大类
1xx 类状态码属于提示信息，实际用到的比较少。
2xx 类状态码表示服务器成功处理了客户端的请求
3xx 类状态码表示客户端请求的资源发生了变动，需要客户端用新的 URL 重新发送请求获取资源，也就是重定向。
4xx 类状态码表示客户端发送的报文有误，服务器无法处理，也就是错误码的含义。
5xx 类状态码表示客户端请求报文正确，但是服务器处理时内部发生了错误，属于服务器端的错误码。
状态码可以由1-5开头的部分三位数，常见的有：
200：表示成功，301：永久重定向，302：临时重定向
403 服务器禁止访问资源，并不是客户端的请求出错。
404：无法找到该页面，405：方法类型不支持，500：服务器内部出错
（2：成功，3：重定向问题，4：客户端报文问题，5：服务端问题）
301和302和304状态码有什么区别
他们都表示资源重定向
「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问，后续访问也都会有新的url。
「302 Found」表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问，以后的访问还是使用旧的url。
301 和 302 都会在响应头里使用字段 Location，指明后续要跳转的 URL，浏览器会自动重定向新的 URL。
「304 Not Modified」不具有跳转的含义，表示资源未修改，告诉客户端可以继续使用缓存资源，用于缓存控制。
502和504是什么意思
502 Bad Gateway：作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。
504 Gateway Time-out：作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器收到响应。
HTTP有哪些请求方式？
比较常见的有GET、POST、DELETE、PUT。
GET：用于请求获取指定资源，通常用于获取数据。
POST：用于向服务器提交数据，通常用于提交表单数据或进行资源的创建。
PUT：用于向服务器更新指定资源，通常用于更新已存在的资源。
DELETE：用于请求服务器删除指定资源。
Get和Post有什么区别
GET 请求主要用于获取数据，参数附加在 URL 中，存在长度限制（不同浏览器限制不一样， FireFox 中 URL 的最大长度限制是 65536 个字符），且容易被浏览器缓存，有安全风险；而 POST 请求用于提交数据，参数放在请求体中，适合提交大量或敏感的数据。
另外，GET 请求是安全且幂等的，多次请求不会改变服务器状态；而 POST 请求不是安全且幂等的，可能对服务器数据有影响，所以浏览器一般不会缓存 POST 请求。
（幂等：执行多次相同的操作结果一样）
不过这都是理论上的区别，如果你实际用get来进行删除内容操作，那肯定也不是安全和幂等的，如果用post来查询，那也是安全且幂等的。所以是否安全和幂等还要看具体操作。
HTTP报文结构说说？
请求报文：
请求行： 请求方法、url 、http协议版本
请求头：附加信息、比如host\Accept(可接受的媒体类型）\Cookie\Range\User-Agent（客户端浏览器类型）
请求体：请求体是可选项，通常Post会存放表单数据，Get不使用请求体
响应报文：
状态行：http协议版本、 状态码、 状态信息
响应头：响应的附加信息，如Content-Type,Content-Length、set-cookie
响应体：通常是返回的html或json内容
http1.0\1.1\2.0有什么区别？
HTTP1.0 默认是短连接，HTTP 1.1 默认是长连接，HTTP 2.0 采用的多路复用。
HTTP1.0:
无状态协议：HTTP 1.0 是无状态的，每个请求之间相互独立，服务器不保存任何请求的状态信息。
非持久连接：默认情况下，每个 HTTP 请求/响应对之后，连接会被关闭，属于短连接。这意味着对于同一个网站的每个资源请求，如 HTML 页面上的图片和脚本，都需要建立一个新的 TCP 连接。（可以设置
Connection: keep-alive强制开启长连接。）HTTP1.1
持久连接：HTTP 1.1 引入了持久连接（也称为 HTTP keep-alive），默认情况下不会立即关闭连接，可以在一个连接上发送多个请求和响应。极大减轻了 TCP 连接的开销。
流水线处理：HTTP 1.1 支持客户端在前一个请求的响应到达之前发送下一个请求，以提高传输效率。不过依然存在响应的队头阻塞问题，所以不常用这个功能。
而且1.1依然是用的明文传输和无状态，所以安全性方面不好，状态方面可以考虑再使用cookie来解决
Http2.0
多路复用：一个 TCP 连接上可以同时进行多个 HTTP 请求/响应，因为它将每个请求 / 响应拆成二进制帧，所有帧通过同一个 TCP 连接传输，帧头部携带 流 ID标识归属的请求。解决了 HTTP 1.1 的队头阻塞问题。
头部压缩：HTTP 协议不带状态，所以每次请求都必须附上所有信息。HTTP 2.0 引入了头部压缩机制，可以压缩后再发送，减少了冗余头部信息的带宽消耗（比如说host\User-Agent这些名字是冗余的）。
服务端推送：服务器可以主动向客户端推送资源，而不需要客户端明确请求，当然这前提肯定是已经建立了连接才行。
HTTPS了解吗？
HTTPS 解决了 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，这其中涉及了非对称加密和对称加密两种加密方式，使得报文能够加密传输。
而TLS握手主要有四次。（HTTPS 默认端口号是 443。）详细流程如下（基于rsa算法，不同的算法过程不太一样）：
客户端与服务器先通过tcp三次握手建立连接
然后客户端发送加密通信请求，会将客户端随机数、密码套件、TLS版本等信息发过去
服务器收到后会确认tls版本是否支持，并选择一个密码套件再生成一个随机数发过去，然后服务端还会发送数字签名。
（数字签名生成流程：首先 CA 会把持有者的公钥等信息打成一个包，然后对这些信息进行 Hash 计算， 然后 CA 会使用自己的私钥将该 Hash 值加密添加在文件证书上，形成数字证书；）
客户端收到后，使用本地的CA公钥确认数字证书的真实性，取出服务器的公钥再加密生成新的随机数发送给服务端，而后续的报文都会被这三个随机数生成的对称密钥加密，不过第三次握手客户端还会发送一个加密报文验证加密是否可用。
服务端收到后会告诉客户端是否加密解密成功，如果成功就算建立了连接。
https一定安全吗？中间人攻击知道吗？
HTTPS 协议本身到目前为止还是没有任何漏洞的，即使你成功进行中间人攻击，本质上是利用了客户端的漏洞，并不是 HTTPS 不够安全。
中间人攻击是是通过一个中间人充当客户端与服务器交互的媒介，他会伪造服务器证书，并取得客户端的信任，然后将客户端的请求转发给服务器，将服务器的响应转发给客户端，完成中间人攻击。
不过由于证书是伪造的所以客户端是会弹出提示窗的，只要我们不继续访问就不会有问题。
http是无状态的吗？怎么样有状态？
HTTP 协议是无状态的，这意味着每个 HTTP 请求都是独立的，服务器不会保留任何关于客户端请求的历史信息。所以我们通常会采用Cookie\session\jwt来实现（目的是验证哪个用户来了，是谁）
Cookie相当于存储在浏览器的标识，长度较短而且不安全，举个例子，好比你去超市存包，柜子给你一张带编号的小纸条（Cookie），上面写着 "你的包在 10 号柜"，接下来几天你都可以用这个柜子，但这张纸条记录的信息很短而且你的纸条有可能被别人偷看所以不安全。
Session相当于存储内容在服务器里，给客户端一个标识去取信息，通常时效性短而且会占用服务器资源。举个例子，你去超市存包服务员用本子记录你的信息，并给你一个柜号，你必须买完东西后赶紧来取。
Jwt主要包括头部、载荷以及签名，头部记录签名算法等信息，载荷会记录一些不敏感的信息，最后是签名，服务器会根据自己的私钥以及签名算法加密，会保证jwt不被篡改
举个例子，你拿身份证住酒店，卡上直接写着你的信息而且有公章，一查这个证件是对的，而一旦证件被改了就会发现，所以只要证是对的就能证明你来了。
http\rpc\websocket说一下
Tcp格式了解吗？
首先就是源端口和目的端口号，因为Tcp是传输层协议，负责端到端的通信，所以要包括端口号
然后就是序列号与应答号，主要告知传输以及接受的位置
还有首部长度，默认是20字节，最大60字节。
标志位ack的话主要是用于传输过程中的，默认传输中都是1，代表应答号有效。
syn主要是三次握手建立连接时使用，表示我想与你建立连接。
fin主要是用于四次挥手的，表示希望断开连接。
rst强制终止连接
然后还有窗口大小、校验和以及紧急指针
你是怎么理解Tcp的？
Tcp是面向连接的可靠的字节流传输协议，建立tcp连接的双方需要维护包括Socket\序列号\窗口大小等信息的，而每一个Tcp连接我们都要通过一个四元组（两ip,两端口）来进行的。
通常用于http、https传输
Udp说说，报文格式了解吗？ip不是有
Udp是无连接的不可靠传输,通常用于dns传输、音视频传输。
Udp头部报文格式只有8个字节，包括源端口号、目的端口号、包长度、校验和。
端口号功能和tcp一样，
包长度包括首部长度和数据长度
而校验和就是为了检查包是否受损
udp和tcp有什么区别？
1、连接：tcp是面向连接的，而udp是不需要连接直接传输的。
2、服务对象：tcp只支持1对1传输，而udp还支持一对多、多对多的通信。
3、可靠性：tcp是可靠交付数据的，而udp是尽最大可能交付，通常是不可靠的，不过我们可以基于udp实现可靠传输
4、拥塞控制、流量控制：tcp有拥塞控制和流量控制、保证传输的安全性。
5、首部开销：tcp最少也要20个字节、但udp只需要8个字节就够了
6、传输方式：tcp是流式传输，把数据拆分成多个 "数据段"，通过网络传输后，在接收端重新拼接成完整的数据流，可能出现两个应用层报文夹杂在一个tcp报文里。udp是一个包一个包发送的，通常客户端能直接知晓发的是哪个请求。
7、分片不同：因为ip层要保证数据包大小小于mtu（1500字节默认），如果运输层超了，tcp会在运输层进行分端，保证不会超过mss(不包含ip头的最大长度），而udp不管，让ip来分片。
为什么udp有包长度没有首部长度、而tcp有首部长度没有包长度？
对于首部长度，tcp有可变长字段选项，所以需要记录首部长度有多长，而udp8个字节所以不需要。
而总长度，其实也就是包长度，因为只需要简单的计算就能算出另一个。tcp总长度是根据ip数据报的总长度减去两个头部算的，而udp的话是自己存储了总长度。
其实这里有个问题，那就是问什么udp也要有数据包总长度而不是直接利用IP算的呢？这里我去查阅了一些资料，我认为比较可靠的答案是说以前网络层可能不止有IP协议，而且协议层之间最好不要高耦合，其实tcp我认为可以在头部的变长字段加一个总长度来实现不依赖网络层计算，而运输层就必须自己存一下了，不过由于IP的发展tcp也不需要额外存储所以没必要加个这个，而udp为了满足对齐要求还是保留了长度字段。
Tcp三次握手说一下
一开始，客户端和服务端都处于 CLOSE 状态。先是服务端主动监听某个端口，处于 LISTEN 状态
客户端会随机初始化序号，将此序号置于 TCP 首部的「序号」字段中，同时把 SYN 标志位置为 1，表示 SYN 报文。接着把第一个 SYN 报文发送给服务端，表示向服务端发起连接，该报文不包含应用层数据，之后客户端处于 SYN-SENT 状态。
服务端收到客户端的 SYN 报文后，首先服务端也随机初始化自己的序号，将此序号填入 TCP 首部的「序列号」字段中，其次把 TCP 首部的「确认号」字段填入 客户端的序列号+ 1, 接着把 SYN 和 ACK 标志位置为 1。最后把该报文发给客户端，该报文也不包含应用层数据，之后服务端处于 SYN-RCVD 状态。
客户端收到服务端报文后，还要向服务端回应最后一个应答报文，首先该应答报文 TCP 首部 ACK 标志位置为 1 ，其次「确认号」字段填入 服务端的序列号 + 1 ，序列号为刚才服务端的应答号，最后把报文发送给服务端，这次报文可以携带客户到服务端的数据，之后客户端处于 ESTABLISHED 状态。
服务端收到客户端的应答报文后，也进入 ESTABLISHED 状态。
TCP的全连接队列与半连接队列说一下
半连接指的是在 TCP 三次握手过程中，服务器接收到了客户端的 SYN 包，但还没有完成第三次握手，而完成第三次握手的连接为全连接队列。
- 当服务端接收到客户端的 SYN 报文时，会创建一个半连接的对象，然后将其加入到「 SYN 队列」；
- 接着发送 SYN + ACK 给客户端，等待客户端回应 ACK 报文；
- 服务端接收到 ACK 报文后，从「 SYN 队列」取出一个半连接对象，然后创建一个新的连接对象放入到「 Accept 队列」；
- 应用从「 Accept 队列」取出连接对象来用
SYN攻击了解吗？
SYN 攻击方式最直接的表现就会把 TCP 半连接队列打满，这样当 TCP 半连接队列满了，后续再在收到 SYN 报文就会丢弃，导致客户端无法和服务端建立连接。
我们可以 减少 SYN+ACK 重传次数：通过
tcp_synack_retries减少 SYN-ACK 的重传次数，加速释放半连接资源
为什么是三次握手不是两次、四次
最关键的一点我认为是三次握手可以防止旧的重复连接初始化。
举个例子，假设客户端由于宕机发送了两次第一次握手报文，如果是三次握手的情况下，旧的报文被服务端收到回了一个第二次握手报文，这时客户端判断不是最新的连接，直接发一个rst终止连接，而等新的报文到了又能与服务端重新连接了。
但是如果是两次握手，服务端收到旧的报文直接进入established状态，然后发送数据，白白浪费服务端资源。而且二次握手还有问题，假如旧的第一次握手在网络中堵住了，客户端重发了并完成了后续的连接操作，等连接结束后旧的报文到达了，这时服务端又开启了无效连接，从而白白浪费资源。
还有就是序列号同步，序列号和应答号总共四个，但服务端可以把序列号和应答号合并起来所以不需要四次握手。而两次握手更不用说了，明明序列号没同步就进入了连接状态显然不合理。
为什么tcp要有mss进行分段,而不是让ip进行分片
因为ip是没有超时重传的机制的，如果丢了某一片报文，tcp就要重发所有报文，这样太低效了，而经过tcp分段后，只需要发丢失的那部分就行了，很高效
（mss的大小通常会在三次握手时商定）
第一次握手丢失了会怎样？第二、三次呢？
第一次握手丢失会触发客户端的超时重传机制（时间由os决定，通常为1s），如果重传了达到一定次数（linux为5），会断开连接。
第二次握手丢失就比较有意思了，因为服务端认为自己没收到第三次握手会重传，而客户端认为自己没收到第二次也会重传，如果重传超过一定次数就会断开连接。
第三次握手丢失更有意思了，此时服务端认为自己没收到第三次握手会重传，而客户端则不会重传ack报文，如果服务端重传超过次数就会断连。
Tcp四次挥手说一下
客户端打算关闭连接，此时会发送一个 FIN 报文，之后客户端进入 FIN_WAIT_1 状态。
服务端收到该报文后，就向客户端发送 ACK 应答报文，接着服务端进入 CLOSE_WAIT 状态。
客户端收到服务端的 ACK 应答报文后，之后进入 FIN_WAIT_2 状态。
等待服务端处理完数据后，也向客户端发送 FIN 报文，之后服务端进入 LAST_ACK 状态。 客户端收到服务端的 FIN 报文后，回一个 ACK 应答报文，之后进入 TIME_WAIT 状态
服务端收到了 ACK 应答报文后，就进入了 CLOSE 状态，至此服务端已经完成连接的关闭。 客户端在经过 2MSL 一段时间后，自动进入 CLOSE 状态，至此客户端也完成连接的关闭。
为什么挥手需要四次？
关闭连接时，客户端向服务端发送 FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据。 服务端收到客户端的 FIN 报文时，先回一个 ACK 应答报文表示我知道了我过一会就不接受了，而服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送 FIN 报文给客户端来表示我也不会再发了，最后客户端回应一个ack表示我知道了我不会再接受了。因为tcp是全双工通信，这里需要对双方的发送接受都关闭才行，所以需要四次。
不过在某些时候也可能只需要三次。
第一次挥手丢失了会怎样？第二三四次呢？
第一次挥手丢失了客户端会重传fin报文，超过一定次数则会强制断开连接。
第二次挥手如果丢失了，那么客户端一直收不到则会重传fin报文，超过一定次数会强制断开连接
第三次挥手如果丢失了，服务端一直收不到客户端的ack报文就会一直重传，如果超过客户端的FIN_wait_2状态时间（默认60秒）则会断连，而服务端长时间收不到ack报文也会断连。
第四次挥手丢失了也就是服务端收不到ack报文会一直重传，而客户端每一次接受后则会重置2MSL计时器并重传ack报文，超过一定次数双方都会断连。
为什么time_wait的时间是2MSL
MSL是报文最大生存时间，Linux 将 MSL 设置为 30 秒，意味着如果超过了30秒对方没收到，那这个报文就消失在网络中了。
2MSL时长这其实是相当于至少允许挥手报文丢失一次。比如若 ACK 在一个 MSL 内丢失，这样服务方重发的 FIN 会在第 2 个 MSL 内到达，TIME_WAIT 状态的连接可以应对，然后可以重发第四次握手报文。
除此之外还能保证连接过程中的丢失报文彻底消失在网络中，如果连接过程中丢包了，而双方断连后重新建立连接，而这时之前的丢包的连接又到达了，这就会造成数据错乱现象。
所以时间如果太短可能会有数据错乱现象，或者服务端重发挥手报文后刚到达客户端就关闭了，本来能有效解决的问题却未能很好解决（会回复rst报文断连，但并不优雅）。而时间太长就得不偿失，因为丢包率通常不大，我们没必要为了允许两次丢包而浪费过多的连接资源，因为本身就是为了断连的，多次丢包的话双方会直接断连，影响不大，所以设定为2MSL比较好。
为什么要time_wait状态？（跟2MSL差不多）
1、防止历史连接中的数据，被后面相同的连接错误的接收。如果连接过程中丢包了，而双方断连后重新建立连接，而这时之前的丢包的数据又到达了，又由于序列号不是无限递增的，会有回绕现象，恰巧这时的序列号包含之前丢包的报文，这就会造成数据错乱现象。
2、还有就是保证服务端能够正确的关闭，客户端必须等待足够长的时，确保服务端能够收到 ACK，如果服务端没有收到 ACK，那么就会触发重传机制服务端会重新发送一个 FIN，而time_wait的2MSL刚好能保证一次丢包的发生，能够正常关闭服务端。（虽然提前一点关闭也可以，因为客户端会回复rst报文断连，但对于可靠传输协议来说最好所有的问题都能被正常解决掉，这样更加优雅）
TIME_WAIT过多会怎样？怎么优化？
首先就是会占用系统资源，文件描述符、内存、线程资源等。
还有就是端口资源，因为无论是客户端还是服务端，可开启的端口是有限的，如果都被Time_wait状态连接占用则无法再开启新连接。
对此也可以进行一些优化，比如复用处于 TIME_WAIT 的 socket 为新的连接所用，不过time_wait状态是有助于我们的连接的，最好不要暴力断开来避免它。
服务器出现大量TIME_Wait状态原因？
如果服务器出现大量time_wait证明服务器是主动断连的，那有可能是http没有开启长连接或长连接超时，这种情况下服务器一般都会申请挥手关闭连接来节省资源的开销。
还有一种可能是http请求数量达到上限，服务端通常有一个参数来定义一条长连接上最大请求数量，如果达到了那么服务端就会请求关闭连接。
已经建立连接但客户端宕机了怎么办？
tcp有个保活计时器，如果长时间没有请求活动，那么服务端会发送一个探测报文来检测客户端是否还在，如果不在了就断开连接。
已经建立连接但服务端进程崩溃怎么办？拔掉网线呢？
Tcp重传机制
最主要有两种：快速重传和超时重传
超时重传比较好理解，就是数据包超时了，这时会重发数据包。
快速重传是发送方收到三个同样ACK的报文，说明该报文大概率丢了，则直接重发一份。
说说TCP的流量控制？
TCP 通过滑动窗口来控制流量
- 接收方通过 TCP 头部的窗口大小字段告知发送方自己的接收缓冲区剩余空间。
- 发送方根据窗口大小调整发送数据的速率，避免接收方缓冲区溢出。
TCP的拥塞控制了解吗？
TCP 通过拥塞控制算法动态调整数据发送速率，避免网络拥塞。拥塞控制的过程：
- 慢启动：初始阶段拥塞窗口大小为1，指数增长发送数据包的速率，即每收到一个ACK，则拥塞窗口x2
- 拥塞避免：当达到慢启动门限后，线性增长发送数据包的速率，即每收到一个ACK，则拥塞窗口+1
- 拥塞发生：发生了丢包的现象，此时有两种情况
- 如果发送方连续收到三个ACK，则快速重传丢失的包（数据驱动，非时间驱动），就不需要等到超时才重传这个包，这时候调整方案是：从新慢开始门限（当前窗口大小/2）+3开始线性增长发送数据包的速率，直到该数据包被正确接受才从新慢开始门限进行拥塞避免算法。这种情况称为：快速重传和快速恢复
- 如果发送方没有连续收到三个ACK，那么会发生超时重传机制（时间驱动），这时候说明网络是真的不行**，所以又回到慢启动状态**，即将拥塞窗口大小变成1，重新进行慢启动算法（慢开始门限为当前窗口大小/2）
TCP的可靠性怎么保证的？
TCP 首先通过三次握手和四次挥手来保证连接的可靠性，然后通过校验和、确认应答、超时重传、流量控制、拥塞控制来保证数据的可靠传输。
三次握手与四次挥手用来建立连接和释放连接
校验和确保数据没有被损毁
确认应答保证数据按顺序传输与接受
超时重传保证数据丢失后能重新发送
流量控制保证数据能正常接受，不会超过接受方的接受能力
拥塞控制是根据网络环境来优化发送速率的。
TCP的粘包和拆包说说
TCP是面向字节流的协议，没有消息边界，接收方无法正确解析经过粘包或者拆包后的数据
粘包：（粘包产生的原因有两种：发送方的行为或接收方的行为）
- 发送方会缓存小数据包，将多个小数据包合并发送，减少网络开销
- 接收方可能因在缓冲区内一次性读取多个包，也会造成粘包
拆包：由于数据包太大，超过最大报文长度，此时发送方需要拆分大数据包，分成多个小数据包再发送
解决方案通常是在上层报文中添加length字段来说明报文有多长，从而定义边界。
什么是csrf攻击？
CSRF，跨站请求伪造，是一种挟持用户在当前已登录的 Web 应用程序上执行非本意的操作的攻击方法。
- 用户登陆银行，没有退出，浏览器包含了 用户 在银行的身份认证信息。
- 攻击者将伪造的转账请求，包含在在帖子
- 用户在银行网站保持登陆的情况下，浏览帖子
- 将伪造的转账请求连同身份认证信息，发送到银行网站
- 银行网站看到身份认证信息，以为就是 用户的合法操作，最后造成用户资金损失。
解决办法：可以使用token验证+多重校验
Dos\DDos
- DOS : (Denial of Service), 翻译过来就是拒绝服务, 一切能引起拒绝 行为的攻击都被称为 DOS 攻击。最常见的 DoS 攻击就有计算机网络宽带攻击 、连通性攻击。
- DDoS: (Distributed Denial of Service)，翻译过来是分布式拒绝服务。是指处于不同位置的多个攻击者同时向一个或几个目标发动攻击，或者一个攻击者控制了位于不同位置的多台机器，并利用这些机器对受害者同时实施攻击。
解决方案：增加带宽、使用防火墙
Xss
XSS 攻击也是比较常见，XSS，叫跨站脚本攻击。它指的是恶意攻击者往 Web 页面里插入恶意 html 代码，当用户浏览网页的时候，嵌入其中 Web 里面的 html 代码会被执行，从而达到恶意攻击用户的特殊目的。
解决方案：输入进行过滤，链接进行校验