大佬教程收集整理的这篇文章主要介绍了计算机网络面试常见问题，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。
5层协议：应用层，传输层，网络层，数据链路层，物理层
TCP/IP分层模型：应用层，传输层，网际层，网络接口层
OSI体系结构：应用层，传输层，会话层，表达层，网络层，数据链路层，物理层
应用层 规定了通信双方的应用进程所遵守的协议。——http、FTP、DNS、Telnet、SSH
传输层 负责给两台主机的应用进程之间的通信提供数据传输服务。———TCP、UDP
网络层 负责选择合适的路由和交换节点，将数据从源端传输到目的端。——IP
数据链路层 负责相邻两个网络节点之间的数据传输。——PPP
物理层 向数据链路层提供透明的传输数据比特流的服务，使数据链路层感受不到不同网络环境的物理设备，传输媒体，通信方式之间的差异
浏览器解析URL，知道要访问哪个域名的哪个资源
@H_197_116@浏览器生成http请求
@H_197_116@浏览器向指定的DNS服务器发送请求，查询服务器域名对应的 IP 地址。
@H_197_116@浏览器通过调用Socket库委托协议栈发送请求，经过 4 个阶段完成数据的收发
创建套接字阶段
创建一个套接字，用于存储“控制信息”，就是协议栈进行数据收发时所需要的关键信息。
@H_197_116@连接阶段
TCP三次握手，建立连接。服务端知道谁将和他通信，并且确保双方能够正常通信。
@H_197_116@通信阶段
浏览器发送数据包。具体描述为：http报文经过协议栈传输层添加TCP头部，经过网络层添加IP头部和MAC头部，经过物理层网卡在头部添加添加起始帧分界符，尾部添加FCS（帧校验序列），最后作为一整个网络包发送到交换机，交换机将他发送到路由器，最后路由到目标主机。
@H_197_116@服务端收到后开始拆快递。数据包从协议栈的下层到上层分别检查Mac头部，IP头部，TCP头部，最终获取到http的请求报文
@H_197_116@然后服务端处理请求，返回一个http响应报文
@H_197_116@断开阶段
TCP四次挥手断开连接。
@H_197_116@@H_197_116@
简单描述一下三次握手的过程：
1.客户端随机初始化一个序列号，把它放在TCP头的序列号字段，之后把SYN标志位设置成1，表示这是一个SYN报文，之后把这个报文发送给服务器，表示希望与服务器建立连接。
2.服务器收到SYN报文之后也随机初始化一个自己的序列号，放入TCP头部的序列号字段，然后把客户端的序列号+1放在TCP头的[确认应答号]字段，然后把SYN和ACK标志位设置成1，返回给客户端。
3.客户端收到后也将服务端的序列号+1放在TCP头部的[确认应答字段]，把ACK标志位置为1，返回给服务端。
到此三次握手完成啦。
三次握手的简洁版：
1.客户端发送一个 客户端序列号 + SYN
2.服务端返回一个 服务端序列号 + (客户端序列号+1) + SYN + ACK
3.客户端返回一个（服务端序列号+1）+ ACK
为什么要进行TCP三次握手？
TCP三次握手是为了在通信双方建立TCP连接。使通信双方知道：
1.对方发送报文的开始序号是多少，
2.对方发送数据的缓冲区的大小，
3.对方能被接受的最大报文段长度（MSS）是多少，
4.能被支持的TCP选项有哪些。
简化：1.建立TCP连接 2. 确保双方能够进行正常通信。
为什么握手需要进行三次？
1.三次握手可以避免建立历史连接。在客户端连续发送多次 SYN 建立连接的报文，在网络拥堵等情况下，旧的SYN可能比新的SYN先抵达客户端，客户端会在第二次握手的时候通过验证系列号来判断是不是一个历史连接，如果是历史连接，就发送 RST 报文终止历史连接，如果不是历史连接，则发送ACK报文成功建立连接。
2.同步双方的初始序列号至少需要三次。
四次挥手的目的:
断开连接
简单描述一下四次挥手：
通信双方都可以主动关闭连接，这里以客户端主动断开连接为例：
1.客服端向服务端发送一个 FIN 报文，请求断开连接。
2.服务端收到后立即返回一个 ACK 报文
3.服务端处理本次连接中需要执行的任务，处理完之后向客户端发送一个 FIN 报文。
4.客户端收到后返回一个 ACK 报文。
5.服务端收到ACK后断开连接
6.客户端经过 2MSL 后断开连接。（Maximum Segment Lifetime：报文最大生存时间）
为什么客户端要2MSL后断开连接才断开连接？
客户端发送给服务器的最后一个ACK报文可能丢失，如果服务器在1个MSL后没有收到ACK就会重新发送一次FIN报文，而客户端就能在这个2MSL时间段内收到这个重传的报文，重传丢失的ACK报文。
@H_197_116@防止新连接建立“历史连接”。在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新连接中就不会接收到旧连接的报文。
@H_197_116@为什么挥手需要四次？
服务端收到客户端的FIN时，会先返回一个ACK，之后还需要进行一些数据的处理和发送，等数据发送完后，才发送 FIN 表示同意关闭连接，因此服务端的 ACK 和 FIN分开发送，需要四次挥手。
TCP头部有序列号字段，接收方会根据序列号对数据包排序，从而保证数据是有序的。
@H_197_116@TCP会进行校验和，检测数据在传输过程中又没有发生改变。
@H_197_116@停止等待：
每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。如果接收端收到错误的报文就丢弃，收到正确报文就回复ACK。如果发送端超多一定时间没有收到ACK就重传。
@H_197_116@为了提高传输效率（信道利用率），发送方可以一次性发送多个 分组（1个发送窗口内的分组），接收方对按序到达的最后一个分组发送确认，表示到这个分组为止的所有分组都已正确接收。这种方式的重传机制是Go-BACk-N：如果发送方发送了前 5 个分组，而中间的第 3 个分组丢失了。这时接收方只能对2个分组发出确认。一段时间后发送方重传后面三个分组。 Go-BACk-N（回退 N），表示需要再退回来重传已发送过的 N 个分组。
@H_197_116@除了[超时重传]，TCP的重传机制还有： [快速重传] [SACK选择性确认]。
@H_197_116@TCP有流量控制（通过滑动窗口实现的），发送发可以根据接收方的实际接受能力控制发送的数据量。
@H_197_116@TCP有拥塞控制，当网络拥塞时，会减少数据的发送，避免加重网络拥塞。
@H_197_116@UDP (User Datagram Protocol) 用户数据报协议
无连接
无连接的优点就是：不存在建立连接需要的时延，也不存在维护连接状态所需要的内存开销。
不可靠
没有 TCP 的[确认机制] [拥塞控制] [重传机制] [流量控制]，不能确定数据包是否安全的、按顺序的到底目的地。
（传输的可靠性需要依赖应用层来完成）
面向报文
对应用层交下来的报文，添加首部后直接向下交付为IP层，既不合并，也不拆分，而是保留这些报文的边界。因此，应用程序需要选择合适的报文大小，避免报文过大或过小，也因此 UDP显得不够灵活，不能控制读写数据的次数和数量。
UDP首部
1.源端口号：需要对方回信时选用，不需要时全部置0. 2.目的端口号 3.长度：UDP的数据报的长度（包括首部和数据）其最小值为8（只有首部） 4.校验和：检测UDP数据报在传输中是否有错，有错则丢弃。该字段是可选的，当源主机不想计算校验和，则直接令该字段全为0.
1.TCP协议是面向连接的，UDP协议是无连接的。
2.TCP是面向字节流的，UDP是面向报文的。
UDP面向报文：UDP对应用层交下来的报文，既不合并也不拆分，而是保留这些报文的边界，也就是说应用层交给UDP多大报文，他就一次性发送多大的报文。
TCP面向字节流：虽然应用程序和TCP的交互是一次一个数据块（大小不等），但是TCP把应用程序交下来的数据仅仅看成是一连串的无结构的字节流，TCP并不知道所传送的字节流的含义。另外如果应用进程传送到TCP缓存的数据块太长，TCP就可以把它划分短一些再传送，如果数据块太短，也可以累积几次一起发送。
3.TCP协议是可靠传输，确保数据时正确的，不会出现重复、乱序；UDP协议是不可靠的。
4.TCP有[确认应答机制] [重传机制] [拥塞控制] [流量控制]，UDP没有。
5.TCP开销大，速度慢，而UDP开销很小，速度块快。因为TCP有维护连接状态，以及保证可靠传输所需要的很多时间和空间的开销，而UDP没有。
TCP 适用于对数据准确性要求比较高的场景，比如 http、文件传输、邮件发送。
UDP适用于对响应速度要求高 允许丢包的场景，比如 视频会议，网络电话。
以上是大佬教程为你收集整理的计算机网络面试常见问题全部内容，希望文章能够帮你解决计算机网络面试常见问题所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。