计算机网络面试题
持续更新…
- OSI七层协议
- 物理层 : 以二进制的流在物理媒介上传输数据
- 数据链路层 : 物理寻址,同时将比特流转换成逻辑传输线路
- 网络层 : 为数据包选择路由
- 传输层: OSI协议中最重要的一层,接受上一层的数据,在必要的时候对数据进行分割,交给网络层,保证数据能到到达对端
- 会话层 : 不同机器上的用户之间建立会话和会话管理
- 表示层 : 数据格式化,代码转换,数据加密
- 应用层 : 文件传输,电子邮件,文件服务,虚拟终端
- tcp协议
- 面向连接的,可靠的,基于字节流的传输层通信协议
- 将应用层的数据流分割成报文段并发送给目标节点的tcp层
- 数据包都有序号,对方收到则发送ack确认,未收到则重传
- 使用校验和来检验数据在传输过程中是否有误
- tcp的三次握手
- 客户端发送syn包[syn=j]到服务器,并进行syn_send状态,等待服务器确认
- 服务器收到syn包,必须确认客户的syn[syn+1],同时自己也发送一个syn包[syn=k],即syn+ack包,此时服务器进入syn_rece状态
- 客户端收到服务器的syn+ack包,向服务器发送确认包ack[ack=k+1],完成后,客户端和服务器进入ESTABLISHED状态,完成三次握手(建立连接)
- 为什么需要三次握手才能建立连接
- 为了初始化Sequence Number的初始值
- 首次握手的隐患-syn超时
- server收到client的syn,回复syn-ack的时候未收到ack确认
- server不断重试至超时,linux默认63秒才断开连接
- 会存在syn blood攻击,就是不同发送连接请求,然后立马下线,占满syn队列
- 针对syn blood的防护措施
- syn队列满后,通过tcp_syncookies参数发回syn cookie
- 若为正常连接,则client会发回syn cookie,直接建立连接
- tcp的四次挥手
- client发送一个fin,用来关闭client到sever的数据传送,client进入fin_wait_1状态
- server收到fin后,发送一个ack给client,确认序号为收到序号+1(与syn相同,一个fin占用一个序号),server进入last_ack状态
- server 发送一个fin,用来关闭server到client的数据传输,server进入last_ack状态
- client收到fin后,client进入time_wait状态,接着发送一个ack给server,确认序号为收到序号+1,server进入closed状态,完成四次挥手
- 为什么会有time_wait状态
- 确保有足够的时间让对方收到ack包
- 避免新旧连接混淆
- 为什么需要四次挥手才能断开连接
- 因为全双工,发送方和接收方都需要fin报文和ack报文
- 服务器出现大量close_wait状态的原因
- 对方关闭socket连接,我方忙于du读或写,没有及时关闭连接
- 解决:
- 检查代码,特别是释放资源的代码
- 检查配置,特别是处理请求的线程配置
- tcp和udp的区别
| tcp | udp |
|---|---|
| 面向连接 | 面向非连接 |
| 可靠性 | 不维护连接转态,支持向多个客户端传输相同的消息 |
| 有序性 | 无序性 |
| 速度慢 | 吞吐量只受限于数据生成速率,传输速率及机器性能 |
| 重量级 | 轻量级 |
- Rtt和Rto
- Rtt:发送一个数据包到收到对应的ack,所花费的时间
- RTO:重传时间间隔
- http协议特点
- 支持客户/服务器模式
- 简单快速
- 灵活
- 无状态
- 无连接
- http请求响应的步骤
- 客户端连接到web服务器
- 发送http请求
- 服务器接受请求并返回http响应
- 释放tcp连接
- 客户端浏览器解析html内容
- 在浏览器输入url,按下回车之后的流程
- DNS解析
- tcp连接
- 发送http请求
- 服务器处理请求并返回htpp报文
- 浏览器解析渲染页面
- 连接结束
- get请求和post请求的区别
- http报文层面:get请求信息放在url中,键值对拼接,post请求在请求体中
- 数据库层面:get请求复合幂等性和安全性,post不符合
- 其他:get请求可以被缓存,post不可以
- http和https的区别
- https需要到ca申请证书,http不需要
- https密文传输,http明文传输
- 连接方式不同,https默认443端口,http使用80端口
- https = htpp+加密+认证+完整性保护,更安全
77
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
