面试笔记-1.计算机网络面试核心

水深无声 2022-11-07 14:33 331阅读 0赞

一.网络

**1.OSI七层模型**

应用层  	：为网络用户之间的通信提供专用的程序和协议
    表示层  	：提供数据压缩、解压、加密等服务，为应用层提供语法选择，语法转换
    会话层  	：建立、管理和终止表示层实体之间的会话连接
    	    : 前三步之后用户的操作便结束了，剩下的是信息如何在网络中传递的问题 
    传输层   ：为会话层提供可靠的、无误的数据传输
    网络层   ：基于IP地址为数据的传输进行网络间的路由选择
    数据链路层：物理地址寻址，为网络层提供数据传送服务
    物理层   ：为数据传输提供物理媒体，进行数据的实际传输

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RpZ2xsZQ_size_16_color_FFFFFF_t_70]

> 无论什么协议，都需要经过两个媒体(发送端和接收端)的所有层

2.**OSI模型和网络四层模型(TCP/IP)的区别**

> 1.TCP/IP四层模型 应用层————（应用层、表示层、会话层） 传输层 网络层 数据链路层——（数据链路层、物理层）
> 
> 1.OSI七层模型属于理论模型，TCP4层模型属于实际应用的模型  
> 2.分层数量不同，OSI七层，TCP/IP四层。  
> 4.OSI的应用层、表示层、会话层再TCP/IP中为应用层，OSI的数据链路层、物理层再TCP/IP中为数据链路层

**3.OSI传输过程**

> 从一个主机的应用层开始自上而下到物理层，每一层都会为数据添加层对应的层头。到达另外一个主机的后，从主机的物理层开始，自下而上，到应用层，每到达一层就会取出层头。

二.tcp

**1.tcp简介**

> TCP（Transmission Control Protocol）传输控制协议，是传输层的协议，提供面向连接的服务，在传送数据之前必须先建立连接，数据传送完成后要释放连接。HTTP、HTTPS、FTP、POP3、SMTP、TELNET、SSH协议都需要运行在TCP之上。

**2.tcp报文**

> 由（报文头+数据部分）组成

**3.tcp报文头**

> 长度：tcp报文长度大小由20字节的固定首部+可变长度

**4.tcp报文头组成**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RpZ2xsZQ_size_16_color_FFFFFF_t_70 1]

> 1.源端口和目标端口（16bit+16bit）（Source Port and Destination Port） TCP传输协议层可以接收多个应用程序的数据，需要通过端口区分目标程序。源端口是指发送端的端口号，目标端口是指接收端的端口号。  
> 2.序列号（32bit）Sequence Number  
> \-------用来标识传输报文的顺序，可根据序列号来重组传输顺序不同的报文，保证数据的可靠性  
> 3.确认号（32bit）Acknowledgment Number  
> \-------仅当ACK标志为1时有效。期望收到对方下一个报文的第一个数据字节的序列号。  
> 4.数据偏移、保留、URG、ACK、PSH、RST、SYN、FIN、窗口  
> \-------1.数据偏移（4bit）（Offset）：记录TCP报文段的首部长度，共占用4位（bit）  
> \-------2.保留（6bit）（Reserved）：6位，必须为0 TCP Flag  
> \-------3.URG（Urgent）（1位）：用0和1表示本报文段中发送的数据是否包含紧急数据。  
> \-------4.ACK（1位）：用0和1表示确认号字段是否有效  
> \-------5.PSH（1位）：用0和1表示接收方是否要尽快将这个报文交给应用层  
> \-------6.RST（1位）：用0和1是否重置连接  
> \-------7.SYN（1位）：同步序号用于连接建立的过程  
> \-------8.FIN（1位）：用0和1标识数据是否发送完毕需要关闭连接  
> \-------9.窗口（16bit）(Window)：指滑动窗口大小，告知发送端和接收端的缓存大小，控制发送端发送数据的速率  
> 5.校验和、紧急指针  
> \-------1.校验和：（16bit）（CheckSum）：由发送端根据数据内容计算一个数值，并由接收端进行验证。接到端的校验和与发送端不一致，TCP将丢弃这个报文也不进行确认（对方就会重复发送了）。  
> \-------2.紧急指针（16bit）（Urgent point）:当TCP Flag的URG为1时才有效，标记紧急数据在数据字段中的位置  
> 6.可选数据（TCP Options）、填充：定义的其他可选参数

**3.tcp Flags**

> 1.URG（1位）：用0和1表示本报文段中发送的数据是否包含紧急数据。  
> 2.ACK（1位）：用0和1表示确认号字段是否有效  
> 3.PSH（1位）：用0和1表示接收方是否要尽快将这个报文交给应用层  
> 4.RST（1位）：用0和1是否重置连接  
> 5.SYN（1位）：同步序号用于连接建立的过程  
> 6.FIN（1位）：用0和1标识数据是否发送完毕需要关闭连接

**4.tcp三次握手流程**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RpZ2xsZQ_size_16_color_FFFFFF_t_70 2]

> 1.第一次握手：客户端将TCP Flag中的SYN置为1，随机产生一个值seq=x，并将该数据包发送给服务器，客户端进入SYN\_SENT状态。 SYN=1 seq=x  
> 2.第二次握手：服务器收到数据包后由标志位SYN=1知道客户端请求建立连接，服务器将TCP Flag的SYN和ACK都置为1，ack=x+1，随机产生一个值seq=y，并将该数据包发送给客户端，服务器进入SYN\_RCVD状态。  
> SYN=1 ACK=1 seq=y ack=x+1  
> 3.第三次握手：客户端收到确认后，检查ack是否为x+1，ACK是否为1，如果正确则将TCP Flag的ACK置为1，ack=y+1，并将该数据包发送给服务器，服务器检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，客户端和服务器进入ESTABLISHED(established)状态，完成三次握手。  
> ACK=1 ack=y+1

**5.为什么需要三次握手**

> 1.初始化Sequence Number的值，后面的数据顺序都是根据Sequence Number排列  
> 2.第一次保证：  
> \-------客户端：自己的发送能力正常。  
> \-------服务器：客户端的发送能力和自己的接收能力正常。  
> 第二次保障：  
> \-------客户端：自己的发送能力、接收能力，服务器的发送能力、接收能力都正常  
> \-------服务器：客户端的发送能力，自己的接收能力接收能力、发送能力都正常。 此时服务器还不知道客户端的接收能力是否正常，所以需要第三次握手。

**6.首次握手隐患，SYN超时攻击和解决办法**

> 当第一次握手后，服务器给客户端回复SYN、ACK后进入SYN\_RCVD状态，此时一直等不到客户端的应答，服务器会重发SYN、ACK，（Linux）重发次数为5次，间隔为从1开始每次翻倍（1x1、2x2、3x3…、5x5），一共花费63秒。然后判断连接超时。 此时可能会受到SYNFlood（DDOS攻击的一种）的攻击：恶意程序不停发送SYN给服务器，然后下线，导致服务器SYN连接的队列耗尽，正常的连接请求不能处理。

> 解决办法：Linux下，当SYN队列满后，TCP会通过原地址端口，目标地址端口和时间戳打造出一个SequenceNumber发回去，简称SYN Cookie，如果是攻击者则不会有响应，如果是正常连接就会再次的把SYN Cookie发回到服务器，服务器就会根据这个Cookie继续建立连接。

**7.连接建立后，客户端出现故障怎么办**

> TCP设有保活机制，在保活时间内，连接处于非活动状态时，开启保活一端会向另一端发送一个保活探测报文，如果发送端没有收到响应报文，那么会根据保活时间间隔将继续发送保活探测报文，直到次数达到保活探测数，此时还没收到响应报文，连接也将被中断。

**8.tcp四次挥手**  
（二者都是EXTABLISHED）

1.第一次挥手：客户端发送第一个数据包，其中Tcp Flag的FIN标志位为1，序列号Seq为x。
    		客户端状态：FIN-WAIT_1
    		FIN=1  seq=x
    2.第二次挥手：服务器收到FIN包后先回复一个包，其中Tcp Flag的ACK=1，序列号seq为y，确认号ack为x+1。
    		客户端状态：FIN-WAIT_2
    		服务器状态：CLOSE_WAIT
    		ACK=1  seq=y  ack=x+1
    3.第三次挥手：服务器再发送第二个包，其中Tcp Flag下的FIN标志位为1、ACK标志位为1，发送序列号seq为z，确认号ack为x+1。
    		服务器状态：LAST-ACK
    		FIN=1  ACK=1  seq=z  ack=x+1
    4.第四次挥手：客户端发方发送第四个包，其中Tcp Flag的ACK为1，序列号为x+1，确认号为z+1。至此，完成四次挥手。
    		客户端状态：TIME-WAIT
    		ACK=1  seq=x+1  ack=z+1
    此时服务器关闭连接，客户端发等待2xMSL时间后（Max Segment Lift time最长报文段时间，linux为30秒）关闭

**9.为什么会有TIME\_WAIT状态**

> 1.主动方在收到被动方的FIN后会发送ACK给被动方，此时如果传输过程被丢弃，会触发被动方重新发送FIN。此时TIME\_WAIT状态的主动方可以重新确认FIN，并再次发送ACK。  
> 2.有时间清空此连接的一些超时重传数据包，避免和下个连接混淆。

**10.服务器出现大量CLOSE\_WAIT的原因和解决方法**

> 原因：被动方在收到FIN代码后没有回复ACK或FIN，可能是程序未关闭连接，也可能是服务器IO被意外阻塞等。  
> 解决：此时需要排查程序或者服务器，及时关闭连接或者解决IO阻塞。

**11.TCP滑窗**

> 1.TCP会话的双方都各自维护一个发送窗口和一个接收窗口。各自的接收窗口大小取决于应用、系统、硬件的限制（TCP传输速率不能大于应用的数据处理速率）。各自的发送窗口则要求取决于对端通告的接收窗口，要求相同。  
> 2.RTT和RTO  
> \-------1.RTT（Round Trip Time）：往返时间，发送方发送数据到接收方回送数据的时间。  
> \-------2.TRO（Retransmission TimeOut）：超时重传机制，tcp发送一个报文时，会启动重传计时器，在计时器规定时间内收到了确认，则删除此计时器，否则重传数据并复位计时器。

三.UDP

**1.UDP简介**

> UDP（User DatagramProtocol）用户数据报协议，是一个无连接的简单的面向数据报的运输层协议，不提供可靠性：只负责发送数据，不负责保证数据的到达。在传输数据前不用建立连接，也没有失败重传，窗口设置，握手挥手等，所以速度比TCP快。DNS、APR等协议运行在UDP上

**2.UDP报文结构**

> 1.原端口（Source Port）、目标端口（Destination Port）  
> 2.数据长度（Length）、校验值（CheckNum）  
> 3.用户数据

**2.TCP和UDP的区别**

> 1.连接和无连接  
> 2.对系统资源的占用（TCP较多，UDP少）  
> 3.数据可靠和不可靠

四.HTTP

**1.HTTP简介（Hyper Text Transfer Protocol）**

> 超文本传输协议，服务器和浏览器之间请求响应式并且无状态的文件传输协议。

**2.HTTP请求结构**  
![在这里插入图片描述][20210312184812928.png]  
**3.HTTP响应结构**![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RpZ2xsZQ_size_16_color_FFFFFF_t_70 3]  
**4.HTTP请求响应步骤 或者 在浏览器地址栏输入URL回车后发生的所有事情**

> 1.当用户在浏览器地址栏输入URL并回车，浏览器会根据域名进行DNS解析：  
> \-------1.浏览器缓存：首先搜索浏览器自身的DNS缓存  
> \-------2.系统缓存：搜索操作系统的DNS缓存  
> \-------3.搜索hosts文件内容  
> \-------4.到远程DNS服务器查找  
> 2.浏览器通过DNS找到目标服务器后，会向其发出TCP请求，通过三次握手建立TCP请求。  
> 3.浏览器发送HTTP请求到目标服务器  
> 4.服务器响应HTTP请求，浏览器通过响应数据获得HTML代码并解析，遇到静态资源时候会重新发起请求。  
> 5.当数据传输完成后，服务器或者浏览器会发起关闭TCP连接请求，进行4次握手关闭TCP连接。

**5.为什么HTTP协议要基于TCP来实现？**

> 目前在Internet中所有的传输都是通过TCP/IP进行的，HTTP协议作为TCP/IP模型中应用层的协议也不例外，TCP是一个端到端的可靠的面向连接的协议，所以HTTP基于传输层TCP协议不用担心数据的传输的各种问题。

**5.HTTP状态码 1.2.3.4.5开头数字开头的状态码代表的含义以及常见状态码**

> 1xx：指示客户端应该继续发起请求  
> 2xx：服务器成功的处理了请求  
> 3xx：重定向，客户端需要采取更多操作来实现请求。  
> 4xx：客户端错误，语法或者请求无法实现。 5xx：服务器错误，服务器不能正常处理请求。

> 常见状态码：  
> 200 OK：服务器正常处理了请求  
> 400 Bad Request：客户端有语法错误，不能被服务器理解  
> 401Unauthorized：请求未授权  
> 403 Forbidden：服务器收到请求，但是拒绝提供服务  
> 404 NotFound：请求资源不存在或URL不正确  
> 500 Internal Server Error：服务器发生错误  
> 503 ServerUnavaliable：服务器当前不能处理客户端的请求，一段时间后可能正常（服务器启动时）

**6.HTTP1.0和1.1和2.0的区别**

> 1.长连接：http1.0默认一次tcp连接进行一次http请求之后就会断开，HTTP1.1中默认开启长连接keep-alive，一个TCP连接上可以传送多个HTTP请求和响应。  
> 2.HTTP/1.1加入了一个新的状态码100，客户端事先可以只发送一个只带头没有Body信息的请求。如果服务器认为客户端有权限请求服务器，则返回100，否则返回401。客户端如果接受到100，才开始把请求body发送到服务器。  
> 3.HTTP1.1支持文件断点续传，当客户端已经有一部分的资源后，只需要跟服务器请求另外的部分资源即可。  
> 3.随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机共享此物理机的虚拟地址。每个虚拟机的Host域不同。HTTP1.0是没有host域的，HTTP1.1才支持这个参数。  
> 4. 在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。

> HTTP2.0  
> 1.多路复用技术(Multiplexing)：HTTP1.1的多个请求必须等上一个请求响应之后接受才能发起下一个请求，所以会受到前面请求的阻塞。HTTP/2多个请求可同时在一个连接上并行执行。某个请求任务耗时严重，不会影响到其它连接的正常执行；  
> 2.服务端推送（server push）：在进行一次请求后，服务器会吧下一次需要请求获得的数据推送给客户端，避免客户端在发一次请求。

**6.GET和POST请求的区别(仔细点)**

> 缓存：GET请求可被缓存，POST请求不会被缓存，但可手动设置  
> 浏览器历史记录：GET请求保留在浏览器历史记录中，POST请求不会保留在浏览器历史记录中  
> 可被收藏为书签：GET请求可被收藏为书签，POST 不能被收藏为书签  
> 长度限制：GET 请求有长度限制（不同浏览器和服务器限制不同），POST请求对数据长度没有要求

**7.Cookie和Session**

> Cookie：  
> Cookie是由服务器端生成，发送给浏览器,浏览器会将Cookie的key/value保存到某个目录下的文本文件内，下次请求同一网站时就发送该Cookie给服务器。格式为key-value形式，用分号隔开。  
> 属性：  
> \-------domain:cookie对于哪个域是有效的。所有向该域发送的请求中都会包含这个cookie信息。如abc.ali.com的cookie，在向def.ali.com发送请求时不会带上此cookie  
> \-------path:表示这个cookie影响到的路径，根据路径细分cookie，浏览器根据细分选择携带的cookie  
> \-------expires：失效时间，表示cookie何时应该被删除的时间戳。默认浏览器会在页面关闭时即将删除所有cookie。如果客户端和服务器端时间不一致，使用expires就会存在偏差。  
> \-------max-age：等于expires的功能，max-age的优先级高于expires。  
> \-------HttpOnly:不允许在浏览器使用document.cookie操作cookie。  
> \-------secure：只有在使用SSL链接时候才在请求中携带cookie。

> Session：  
> 服务器可以为每个用户浏览器创建一个会话即session。服务器根据需求设置session，将会话信息保存在服务器上，同时将标示session的session\_id传递给客户端浏览器。浏览器每次请求都会带上由服务器为它生成的session\_id。

**8.Cookie和Session的区别**

> 1.cookie数据保存在客户端，session数据保存在服务器端。  
> 2.Session比Cookie安全。  
> 3.因为Session是保存在服务器上，如果Session过多会影响服务器的性能。  
> 4.Session虽然保存在服务器上，但其生成的标识sessionId保存在cookie中

六.HTTPS

**1.HTTPS简介**

> HTTPS=HTTP+SSL/TLS

**2.HTTP和HTTPS的区别**

> 1.HTTP采用明文传输数据，不安全。HTTPS经过证书认证，数据加密传输，比较安全。  
> 2.HTTP不需要购买证书，HTTPS需要购买证书  
> 3.HTTP的默认端口为80,HTTPS的默认端口为443。

**3.SSL介绍**

> 安全套接字（Secure Socket Layer，SSL）协议是Web浏览器与Web服务器之间安全交换信息的协议，提供两个基本的安全服务：鉴别与保密

> 1.鉴别：可选的客户端认证，和强制的服务器端认证。  
> 2.保密：在握手协议中定义了会话密钥后，所有的消息都被加密

。

**4.HTTPS的加密方式**

> 1.对称加密：加密和解密都是同一个密匙。  
> 2.非对称加密：密钥成对出现，分为公钥和私钥，公钥加密需要私钥解密，私钥加密需要公钥解密。

**5.HTTPS数据传输流程**  
1.简易  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RpZ2xsZQ_size_16_color_FFFFFF_t_70 4]  
2.详细  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RpZ2xsZQ_size_16_color_FFFFFF_t_70 5]

> 1.服务器向CA申请证书，CA生成一个公钥并与证书绑定在一起，颁发给服务器  
> 2.浏览器向服务器发起请求，告诉服务器自己支持的加密协议和版本，服务器选择合适的加密协议，然后服务器返回证书以及公钥  
> 3.浏览器用内置的CA证书（浏览器或者操作系统在安装时默认就会植入一些世界公认的可信任CA机构的证书）与服务器的证书进行验证，并获取公钥  
> 4.浏览器采用服务器选择的算法生成对称密钥，用服务器给的公钥将对称密钥加密，发给服务器。  
> 5.服务器采用私钥解密拿到对称密钥，应用此对称密钥与选择的算法进行数据加，然后将加密后的数据发送给浏览器  
> 6.浏览器通过对称密钥将数据解密  
> 7.之后浏览器就通过此对称密钥进行报文的传输

七.socket

**1.socket简介**

> Socket是操作系统对TCP/IP协议的抽象和封装，并对外开放的接口

**2.java中使用socket进行tcp和upd通信**

> TCP：  
> ServerSoket ss 服务器端  
> Socket s= ss.accept();监听=========客户端：Socket s = new Socket(host,port);  
> is = s.getInputStream();读取内容  
> os = s.getOutPutStream();  
> os.write(…);写内容

> UPD:  
> DatagramSocket s = new DatagtamSocket(65001);//服务器  
> DatagramPacker packet = new DataGramPacket(byte\[\],byte\[\].length);  
> s.receive(packet); Data d = packet.getData();//接收数据  
> s.send(packet); //发送数据

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RpZ2xsZQ_size_16_color_FFFFFF_t_70]: /images/20221023/cdbcbe8f6f144ef3b22f942cf9e9ebd1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RpZ2xsZQ_size_16_color_FFFFFF_t_70 1]: /images/20221023/b00e589e9b95424ca7e055769f8f171c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RpZ2xsZQ_size_16_color_FFFFFF_t_70 2]: /images/20221023/4308f3c81a5d4834a44f90f502e9d85a.png
[20210312184812928.png]: /images/20221023/99257e3080944fef9a7b6f38a81c5f91.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RpZ2xsZQ_size_16_color_FFFFFF_t_70 3]: /images/20221023/e81d28fac1af48e1a16c0bf8974b04cc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RpZ2xsZQ_size_16_color_FFFFFF_t_70 4]: /images/20221023/427e487fc7fc4ff883e821ea6ccc93ba.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RpZ2xsZQ_size_16_color_FFFFFF_t_70 5]: /images/20221023/7ab546d885264c18881141f55cc3b44e.png