小伙伴们大家好 ,本篇文章开始为大家准备大厂面试题 ,为大家的 春招,秋招,校招,提前批,实习 做好准备,争取为大家尽可能详细的为大家讲解计算机的重点知识,剖析大厂的面试题,分析其中的知识点。希望大家都能学到很多东西,进入自己理想中的公司!!!
以下就是完整的学习路径哦。
↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓
↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑
推荐大家认真学习哦!!!
我们这里先介绍一下计算机网络的相关知识
ip : 设备在网络中的地址, 唯一标识
端口号 : 应用程序在设备中的唯一标识
协议 : 数据在网络传输中的规则 , 常见的协议有UDP ,TCP , HTTP , HTTPS , FTP
假设IP地址为IPv4,即32位二进制数,端口号是16位二进制数。由于IP地址和端口号组成的连接是唯一的,因此可以用乘法原理计算可行的连接数量。
IP地址的二进制表示法中,每一位都有两个可能的状态0或1,因此有==232**==个不同的I**==P地址==**。端口号的二进制表示中,每一位也有两个可能的状态0或1,有==**216==个不同的**端口号**。
因此,将IP地址和端口号组合在一起可以得到 2^32 * 2^16 = 2^48 (281,474,976,710,656)
种唯一的连接。
需要注意的是,这只是理论上的最大连接数量,在实际应用中,每个系统都有其自己的限制和限制条件。例如,在某些操作系统或网络设备中,可能会限制最大端口号或同一IP地址上的最大连接数量等。
TCP(传输控制协议, Transmission Control Protocol)和UDP(用户数据报协议 , User Datagram Protocol)是两种常见的网络传输协议,它们在功能和特点上有以下区别:
连接性:
可靠性:
TCP提供可靠的数据传输。它使用 确认和重传机制来确保数据的可靠性 。发送方将数据切割成适当大小的数据包,并等待接收方的确认消息。如果发送方没有收到确认消息,它会重传该数据包。
UDP不提供可靠性保证。它仅仅是将数据包发送出去,不关心是否能够到达目标机器或者是否丢失数据。应用程序需要自行处理数据的可靠性问题。
有序性:
数据量:
延迟:
一句话概括 : TCP提供了可靠性、有序性和流量控制等功能,适用于对数据可靠性要求较高的应用,如文件传输、网页浏览等。UDP则更适用于实时性要求较高、对数据可靠性要求较低的应用,如音视频流媒体、游戏等。选择使用TCP还是UDP取决于具体应用的需求和性能要求。
实质上其实就是连接服务器指定端口,建立TCP连接,并同步连接双方的序列号和确认号,交换TCP窗口大小
信息。
最全面的整体如下 , 以下要求全文背诵 :
服务端建立套接字(socket
),绑定(bind
)地址信息后开始监听(listen
),进入LISTEN状态。调用accept阻塞式获取
客户端新建套接字绑定地址信息后调用connect
,发送连接请求SYN,并进入SYN_SENT状态,等待服务器的确认。
服务端一旦监听到连接请求,就会将连接放入内核等待队列中,并向客户端发送SYN和确认报文段ACK,进入SYN_RECD状态。
这里解释以下内连接队列:
内核等待队列(也称为连接队列或半连接队列)是在服务器端用于存放已接收到的连接请求但尚未完全建立连接的队列。
当服务端监听到一个连接请求时,会将该连接放入内核等待队列中。服务端会向客户端发送一个SYN报文段作为响应,表示接受连接请求,并等待客户端发送确认报文段ACK来确认连接的建立。
此时,连接处于SYN_RECEIVED(SYN_RCVD)状态,表示服务端已经接收到客户端的SYN报文段,并等待客户端发送ACK报文段,以完成连接的建立。在这个阶段,连接还没有完全建立,仍然需要进一步的握手过程。
内连接队列的作用是确保服务器能够适当地处理连接请求,即使服务器尚未准备好处理新的连接或已达到处理连接的最大数量限制。通过将连接请求放入内连接队列,服务器可以暂时保存这些连接,直到它们被接受或拒绝。
如果内连接队列已满,新的连接请求可能会被服务器拒绝或忽略,这可能导致客户端无法建立连接。因此,在设计服务器应用程序时,需要根据预期的负载和性能需求来合理配置内连接队列大小,以确保不会因为过多的连接请求而导致丢失连接或拒绝服务的情况发生。
客户端收到SYN+ACK报文后向服务端发送确认报文段ACK,并进入ESTABLISHED状态,开始读写数据。
服务端一旦收到客户端的确认报文,就进入ESTABLISHED状态,就可以进行读写数据了
完成三次握手后,TCP连接建立成功,双方可以开始进行数据传输。
因为第二次的时候 , 客户端能得出服务端发送数据和接受数据的能力正常, 但是服务端不能得出客户端接收能力是否正常。
第三次握手客户端发送ACK,服务器接收,服务端才能得出客户端发送接收能力正常,服务端自己发送接收能力也都正常。
同样 ,以下要求全文背诵哈 :
2MSL是指两倍的最大报文段生存时间(Maximum Segment Lifetime)。
在TCP的四次挥手(Four-way Handshake)过程中,当客户端发送最后一个ACK确认报文段后,服务器进入TIME_WAIT状态并等待一段时间,这个时间就是2MSL。
MSL是 指报文段在网络中最长的存活时间,正常情况下 大约为一个IP数据包在互联网中能存活的最长时间。因此,2MSL就是一个较为保守的等待时间,确保所有的报文段都从网络中消失,避免出现旧连接的报文段对新连接造成干扰。
在2MSL的等待过程中,服务器会 阻塞该端口,不接受相同本地地址/端口和远程地址/端口组合的新连接请求。这样做是为了确保所有的报文段都被网络丢弃,以防止可能延迟到达的报文段被错误地解释为属于旧连接的一部分。
通过等待2MSL的时间,可以确保旧连接的所有可能残留报文段都已经消失,从而保证了网络的稳定和可靠性,并允许资源能够被重用。
需要注意的是,2MSL的值通常取决于具体的操作系统和网络环境配置,默认情况下一般为30秒到2分钟之间。
对于四次挥手,由于TCP是全双工通信,主动关闭方发送FIN请求不代表完全断开连接,只能表示主动关闭方不再发送数据了。
而接收方可能还要发送数据,就不能立即关闭服务器端到客户端的数据通道,所以就 不能将服务端的FIN包和对客户端的ACK包合并发送只能先确认ACK,等服务器无需发送数据时在发送FIN包 ,所以四次挥手时需要四次数据包的交互。