网络编程八股文

tcp粘包问题？

tcp接收端收到了几个数据包结合在一起的包，
这个协议本身是以流的形式来传送，
tcp实际上没有粘包问题，

解决方案：
1.使用标准的应用层协议。
2.尾部添加特殊字符
3.在发送数据块之前，添加包头。
tcp中的分包、粘包问题。
原因是发送数据太快， 或者接收数据太慢，
导致服务接收端直接打印，
加上字符串长度，然后读取指定数据字符串。

---

BIO,NIO,AIO是什么？

BIO: 同步阻塞io, 使用BIO读取数据时候， 线程会阻塞住， 并且需要线程主动查询是否有数据可读，
并且需要处理完一个Socket之后才能处理下一个socket.
NIO:同步非阻塞IO, 使用NIO读取数据的时候， 线程不会阻塞， 但需要线程主动去查询是否有IO事件。
AIO：异步非阻塞IO, 使用AIO读取数据的时候， 线程不会阻塞， 并且当有数据可读时候， 会通知给线程， 不需要线程主动去查询。

---

零拷贝是什么？

原来是需要走 内核中read buffer -> 应用程序的buffer -> 内核中socket buffer -> 网卡buffer
==> 优化后， 不需要应用程序从中间来交换
read buffer -> 使用transferTo()调用 -> 内核中socket buffer -> 网卡buffer
少了2次拷贝动作。

---

浏览器发出一个请求到收到响应的具体步骤？

1.浏览器解析用户输入的url， 生成一个http格式请求
2.根据url域名从本地host文件中查找是否有映射ip, 如果没有就将域名发送给电脑所配置的DNS进行域名解析，
得到ip地址
3.浏览器通过操作系统将请求通过四层网络协议发出。
4.途中经过各种路由器、交换机、最终到达服务器
5.服务器收到请求后， 根据请求所指定的端口， 找到对应应用程序，
6.收到数据后， 按照http格式进行解析， 得到所有访问的接口
7.处理业务逻辑，
8.处理好后封装http响应内容， 再次通过网络返回请求客户端
9.浏览器所在服务器拿到结果， 传递到浏览器， 解析并且渲染。

---

select, poll, epoll区别是什么？

select模型， 使用的数组来存储socket连接文件描述符， 容量是固定的， 需要通过轮询来判断是否发生了IO事件
poll模型， 使用的是链表来存储socket连接文件描述符， 容量是不固定的， 同样需要通过轮询来判断是否发生了IO事件
epoll模型， epoll是一个事件通知模型， 当发生了IO事件时， 应用程序才进行IO操作， 不需要像poll模型那样去轮询。

---

https是如何保证安全传输的？

https通过使用对称加密、非对称加密、数字证书等方式来保证数据安全传输。
1.客户端向服务器发送数据之前， 需要先建立tcp连接， 所以先建立tcp连接， 建立完tcp连接后， 服务端会先给客户端发送公钥， 客户端拿到公钥后就可以用来加密数据了，
服务端到时候接收到数据， 就可以用私钥解密数据， 这种就是通过非对称加密来传输数据。
2.不过非对称加密对比对称加密要慢， 所以不能直接使用非对称加密来传输请求数据， 所以可以通过非对称加密的方式来传输对称加密的密钥， 之后就可以使用对称加密来传输请求数据了。
3.但是仅仅通过非对称加密+对称加密不足以能够保证数据传输的绝对安全， 因为服务端向客户端发送公钥时，可能会被截取。
4.所以为了安全的传输公钥， 需要用到数字证书， 数字证书是具有公信力、大家都认可的， 服务端向客户端发送公钥时， 可以把公钥和服务端相关信息通过hash算法生成消息摘要， 再通过数字证书
提供的私钥对消息进行加密生成数字签名， 再把没进行hash算法之前的信息和数字签名一起形成数字证书， 最后把数字证书发送给客户端， 客户端收到数字证书后， 就会通过数字证书提供的公钥来解密
数字证书， 从而得到非对加密要用的公钥。
5.这个过程中， 就算有中间人拦截到服务器端发出来的数字证书， 虽然它可以解密得到非对称加密要用到的公钥， 但是中间人是没办法伪造数字证书发给客户端的， 因为客户端上内嵌的数字证书是全球
公信力的， 某个网站如果想支持https, 都是需要申请数字证书的私钥的， 中间人如果要生成能被客户端解析的数字证书， 也要申请私钥， 所以比较安全。

---

tcp的三次握手和四次挥手：

建立tcp:
1.客户端向服务端发送一个
SYN
2.服务端接收到syn后， 给客户端一个sync_ack
3.客户端收到syn-ack后， 给服务端再发一个ack

断开时候：
1.客户端发送fin
2.服务端收到后， 发送ack， 表示我收到了断开请求， 不过服务端可能还有数据正在处理
3.服务端处理完数据后， 向客户端发送fin, 表示服务端现在可以断开连接
4.客户端收到服务端fin, 向服务端发送ack, 表示客户端也断开连接了。

---

tcp网络分层：

传输层： 提供端口对端口的服务。8080（Tcp协议） ， 加上tcp报文头
网络层： 加上IP报文头， ip地址， 从地址到地址
网络链路层： 以太网报文头， mac地址，
物理层： 比特流

---

网络分层的好处：

1.各层独立， 不需要知道上下层如何工作， 增加或者修改不会影响传输层协议
2.灵活性更好， 比如路由器不需要知道应用层和传输层， 分层后路由器就可以
只用加载更少的几个协议层
3.易于测试和维护， 提高可测试性， 可以独立的测试特定层， 某一层
有了更好的实现可以整体替换掉
4. 促进标准化， 每层职责清晰， 方便进行标准化。

---

tcp三次握手为什么3次， 为什么不是2次或者4次？

tcp是面向连接的传输， 所以需要2端都做好准备，即面向双方的。
如果只有2次， server端就可能单方面认为连接建立，
造成server端连接资源的浪费。
四次浪费报文资源。

---

tcp的四次挥手为啥必须是4次？

如果优化成3次， 那么server端可能某些资源可能没释放，
中间可能有比较大的延时或者时差，
等太长时间超过超时时间后， 还会造成消息重发，
造成资源浪费。
这样才能达到效率最高。

---

为什么syn/fin不包含数据却要消耗一个序列号？

凡是对端确认的， 一定消耗tcp报文序列号。

---

tcp流量控制机制

对于发送端和接收端而言， tcp需要把发送的数据发送到
发送缓冲区， 将接收到的数据放到接收缓冲区。
流量控制就是通过接收缓冲区大小，控制发送端的发送。
如果对方接受缓冲区满了， 就不再发送。
为了控制发送端速率， 接收端会告知客户端自己的接收窗口，
也就是接收缓冲区的空闲部分。
ack确认的时候， 会带有窗口的大小。




滑动窗口限流。

---

tcp中keep-alive原理。

通过定时发送探测包来探测连接的对端是否存活，
不过默认情况下是7200秒， 没有数据包交互才会发送
keep-alive探测包， 往往这个时间太久了， 我们熟知的很多组件都没有开启keep-alive特性 ，而是选择在应用层做心跳机制。

---

tcp中的端口号？

端口号在传输层tcp报文头中。， 一台主机最大允许65536个端口号。


熟知端口号： 0-1023
http:80
https: 443
ssh:22

已登记端口号：
mysql:3306
redis:6379
mongodb:27017

---

telnet主要用法：

telnet最大作用是检查一个端口是否处于打开，
telnet ip port 这条命令可以告诉我们远端server指定端口的网络连接是否科大。

---

netstat用法：

netstat 主要用于显示各种网络相关信息：
-a：显示所有选项， 默认不显示Listen相关
-t(tcp): 仅仅显示tcp相关
-u(udp):仅仅显示udp相关选项
-n 拒绝显示别名， 能显示数字的全部转为数字
-l ：列出在listen的服务状态
-p: 显示建立相关链接的程序名
-r: 显示路由信息， 路由表

---

tcpdump的用法

tcpdump是一个抓包工具， 是一个网络流量抓包工具，
一般用来抓tcp的包。
tcpdump -i any 抓取任意端口的包。
sudo tcpdump -i any host 112.80.248.76
tcpdump -i any host www.baidu.com

---

tcp和udp区别：

tcp是面向连接的， 可靠的， 基于字节流的传输层协议
udp是面向无连接的传输层协议。
面向连接指的是客户端和服务器端的链接， 在双方互相通信之前
tcp需要建立3次握手， 而udp没有建立连接的过程。

可靠性：tcp花了很多保证连接可靠，
1.tcp有状态， tcp会精确记录那些数据发送了， 那些没有，
哪些被对方接受了， 哪些没有被接收到， 而且保证数据包
按序到达， 不允许半点出错。

2.tcp可控制， 意识到包丢了或者网络环境差， tcp会根据
具体情况调整自己的行为， 控制自己发送的速度或者重发。

---

慢开始、拥塞避免、快重传、快恢复

慢开始
最开始从0开始， 拥塞窗口默认是最小为1.

每收到一次确认， 原来的拥塞窗口+1， 直接翻倍。
慢开始指的是最初注入到网络中的报文段数量。
指数级增加方式。
拥塞避免：
ssthresh: 慢开始门限值，
根据当前网络拥塞程度估算当前阈值， 一般是根据往返时延。
估算一个临街值， 调整窗口大小，
原来拥塞值到达之前， 指数增加， 到达之后， 采用线性增加。
到达网络拥塞之前这段线性增加的过程就是拥塞避免算法， 是线性增加的。
当到达实际网络拥塞的时候（出现超时了），

ssthrsh的值降为拥塞的窗口大小的一半。
发送窗口调整为最小值1开始。

快重传：

收到3个重复的ack确认报文， 执行快重传算法， 可能报文丢失。
不用等待超时， 然后提前执行重传的过程。
快恢复：
慢开始门限起点直接定位拥塞的上限的一半， 然后线性增大。
跳过了从1恢复的过程。

生产环境中， 上面4种情况都可能会用到。

---

tcp建立连接过程中， 服务端会维护哪2个队列？作用是什么？

在TCP建立连接的过程中，服务端会维护两个队列结构，这两个队列分别是：

1. 监听队列（Listen Queue，也称为未完成连接队列）：

   • 当服务端的程序调用listen函数后，会创建一个监听队列，用于存放客户端发起连接请求的握手请求（SYN）。
   • 当客户端发起连接请求时，服务端的操作系统会将该连接请求放入监听队列中，并发送一个握手响应（SYN-ACK）给客户端。

2. 已连接队列（Established Queue）：

   • 当客户端的握手响应（SYN-ACK）到达服务端后，服务端的操作系统会将该连接从监听队列中取出，并将其移到已连接队列中。
   • 这样，服务端和客户端之间的TCP连接就建立成功，可以进行数据的传输了。

需要注意的是，监听队列和已连接队列是服务端操作系统内部维护的数据结构，用于处理连接请求的握手过程。监听队列用于暂时存放连接请求，待服务端接受请求后，将连接从监听队列移到已连接队列中。而已连接队列则用于维护已建立的TCP连接，用于后续的数据传输。

同时，需要注意的是这些队列的长度是有限的，如果连接请求过多超过了队列长度，后续的连接请求可能会被丢弃或被客户端认为连接超时。这是因为TCP连接的握手过程需要保持一定的资源开销，因此服务端对连接请求的数量和频率有一定的限制。

---

time_wait过多会有什么影响？应该怎么优化？

当服务器上的TCP连接处于大量的TIME_WAIT状态时，会出现一些影响和潜在的问题，包括：

1. 资源消耗： TIME_WAIT状态的TCP连接会占用服务器资源，包括内存和端口资源。虽然TIME_WAIT状态的连接并不消耗太多内存，但大量的TIME_WAIT连接可能导致端口耗尽，尤其在短时间内频繁建立和关闭连接的情况下。

2. 连接限制： 操作系统对于TIME_WAIT连接的处理有一定限制。当连接数达到一定阈值时，操作系统可能会拒绝建立新的连接，从而影响新的客户端连接请求。

3. 性能下降： 大量TIME_WAIT连接可能会导致TCP连接池耗尽，影响服务器的性能，特别是在高并发的情况下。

4. 端口耗尽： 在客户端主动关闭连接时，操作系统会将连接保持在TIME_WAIT状态，以确保最后一个ACK包可以到达。如果客户端频繁建立连接并主动关闭，服务器上的端口可能会耗尽，导致无法建立新的连接。

为了减轻TIME_WAIT过多带来的影响，可以采取以下措施：

• 调整TCP连接的TIME_WAIT超时时间，使其较短，从而释放连接更快。
• 调整操作系统的端口范围，确保有足够的端口资源供连接使用。
• 使用连接池和复用连接，避免频繁地建立和关闭连接。
• 如果可能，使用长连接而不是短连接，减少TIME_WAIT状态的产生。

总体而言，对于大量的TIME_WAIT连接，需要仔细优化系统参数和设计，以确保服务器的稳定性和性能。

---

长连接和短连接区别是什么？

长连接（Keep-Alive）和短连接是两种不同的网络连接方式，它们的主要区别在于连接的生命周期和复用方式：

1. 长连接（Keep-Alive）：

   • 长连接是指在建立连接后，客户端和服务器之间保持连接持续打开的状态，允许在单个连接上进行多次请求和响应。
   • 客户端和服务器之间的连接不会立即关闭，而是在一段时间内保持打开状态，以便后续请求可以复用该连接。
   • 适用于需要频繁通信的场景，可以减少连接的建立和关闭开销，提高性能。
   • 常见的应用场景包括Web服务器、即时通讯应用等。

2. 短连接：

   • 短连接是指客户端和服务器在每次请求和响应完成后立即关闭连接，每个请求都需要重新建立一个新的连接。
   • 客户端和服务器之间的连接在每次请求后都会立即关闭，不会保持持久连接状态。
   • 适用于不需要频繁通信的场景，每次请求都是一个独立的连接，可以避免资源占用和连接的资源浪费。
   • 常见的应用场景包括SMTP、FTP等传统的应用协议。

总体来说，长连接适合需要频繁通信和低延迟的场景，因为避免了频繁的连接建立和关闭开销。而短连接适合不需要频繁通信的场景，每次请求都是一个独立的连接，可以避免资源占用和连接的资源浪费。选择长连接还是短连接取决于具体的应用场景和需求。

---

http, https, http2各有什么特点？

HTTP, HTTPS和HTTP/2是三种不同的协议，用于在客户端（例如浏览器）和服务器之间传输数据。它们各自有一些特点：

1. HTTP（超文本传输协议）：

   • 特点：HTTP是最早的用于传输数据的协议，用于在Web浏览器和Web服务器之间传递超文本文档，如HTML页面。
   • 工作方式：它是一种无状态协议，每个请求和响应之间没有保持状态，因此服务器不会保存关于客户端的信息。
   • 安全性：HTTP传输的数据是明文的，不加密，因此容易受到窃听和篡改的风险。
   • 端口：默认端口为80。

2. HTTPS（安全超文本传输协议）：

   • 特点：HTTPS是在HTTP基础上添加了安全层的协议，用于加密传输数据，使通信更加安全。
   • 工作方式：通过使用SSL（安全套接层）或TLS（传输层安全）协议，对传输的数据进行加密和解密，确保传输过程中的数据安全性和完整性。
   • 安全性：传输的数据是经过加密的，因此更难以被窃听和篡改。
   • 端口：默认端口为443。

3. HTTP/2（超文本传输协议第2版）：

   • 特点：HTTP/2是HTTP/1.1的升级版，旨在提高性能和效率。
   • 工作方式：HTTP/2使用二进制协议而不是文本协议，通过多路复用技术，在单个连接上同时处理多个请求和响应，从而减少延迟并提高加载速度。
   • 特性：HTTP/2支持服务器推送，服务器可以在客户端请求之前主动发送资源，加快页面加载时间。
   • 安全性：与HTTP一样，HTTP/2的数据传输是明文的。为了增加安全性，通常与HTTPS一起使用，称为HTTP/2 over TLS（HTTP/2加密传输层）。
   • 端口：HTTP/2通常使用与HTTP相同的端口，即80或443。

总结：

• HTTP是最早的协议，不加密传输数据。
• HTTPS是对HTTP的安全升级，通过加密传输数据，提高数据安全性。
• HTTP/2是HTTP的性能升级，通过二进制协议和多路复用技术提高加载速度和效率。通常与HTTPS一起使用以增加安全性。

---

什么是跨域问题？

跨域（Cross-Origin）问题是指在Web浏览器中，当一个网页（或Web应用程序）尝试从一个域（或网站）获取资源或与另一个域进行数据交互时，出现了安全限制。简而言之，当一个网页的源（Origin）与另一个网页的源不同，就会发生跨域问题。

浏览器出于安全考虑实施了同源策略（Same-Origin Policy），这是一种安全机制，它限制了一个网页从另一个源（域、协议或端口）获取资源或与其进行交互。同源策略有助于防止恶意网站窃取用户数据，但同时也限制了一些合法的资源获取和数据交互行为。

同源策略要求以下三个条件完全相同，才能认为两个页面同源：

1. 协议相同：两个页面的协议（如http、https）必须相同。
2. 域名相同：两个页面的域名部分（如example.com）必须相同。
3. 端口相同：如果在URL中指定了端口号，则两个页面的端口号必须相同。

如果不满足同源策略的条件，浏览器将阻止页面间的资源获取和数据交互，这就是跨域问题。跨域问题可以在浏览器的开发者工具控制台中看到错误信息，例如：

Access to XMLHttpRequest at 'http://example.com/api/data' from origin 'http://differentdomain.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

要解决跨域问题，需要通过服务器端的配置来设置允许跨域访问，其中一个常用的解决方案是使用CORS（Cross-Origin Resource Sharing）机制，在服务器端添加相应的响应头，告知浏览器哪些域是允许跨域访问的。另外，还可以使用JSONP、代理等技术来实现跨域资源共享。