Tim

一枚野生程序员~

  • 主页
  • 分类
  • 标签
  • 归档
  • 关于
所有文章 工具

Tim

一枚野生程序员~

  • 主页
  • 分类
  • 标签
  • 归档
  • 关于

计算机网络常见面试题

阅读数:次 2020-01-25
字数统计: 2.8k字   |   阅读时长≈ 10分

mark

这篇文章主要是谈谈计算机网络常见的面试个考察点,记录一下,里面有很多问题之前面试也遇到过,特此记录一下!

0、讲一下TCP三次握手

0、TCP三次握手是一个TCP连接的建立过程,为了确认双方的收发能力正常,并初始化seq,为后续传输做准备

1、首先Client处于Closed状态,Server处于Listen状态,Client向Server发了SYN=1,seq=x,Server收到后确认了Server的接收能力正常,Client的发送能力正常;

2、Server回复SYN=1,ACK=1,ack=x+1,seq=y,Client收到后做出判断:Client和Server的收发能力都正常,

3、接着Client向Server发ACK=1,seq=x+1,ack=y+1,这就是第三次握手,可以携带数据了,Server收到后便可以确认Client接收能力正常,Server发送能力正常,并把链接从半连接队列移动到全连接队列

1、seq是固定的吗

seq是随时间变化的,每个连接都有不同的seq,seq是一个32byte的计数器,每4ms加一,因此seq是动态生成的,为后续传输做准备

2、三次握手可以携带数据吗

只有第三次可以携带数据,如果第一次就能携带数据的话服务器会花很多时间对数据进行存储,占用IO资源,非常危险,对于第三次握手来说Client已经知道双方的收发能力正常,所以携带数据也是没问题的

3、什么是半连接队列

第一次握手后,Server发出ACK报文,等待Client向自己发送ACK报文,此时就会把请求放在半连接队列,半连接队列满了就会丢弃报文

4、谈谈SYN攻击

Client向Server发SYN=1,seq=x,收到Server发来的ACK不回复ACK,或者直接丢弃Server的ACK报文,导致半连接队列满了,丢弃了其他真实需求的请求报文,导致服务器无法正常提供服务

5、第三次握手丢失,会怎样

服务端会重传,如果收到就会停止,尝试时间间隔为1s、2s、4s、8s、16s、32s、64s,Linux最多尝试64s,之后若还是无应答就会移出半连接队列

6、Linux如何判断受到了SYN攻击

1
netstat -n -p TCP|grep SYN_RECV

7、Linux查看网络状态

1
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

它会显示例如下面的信息:

TIME_WAIT 814
CLOSE_WAIT 1
FIN_WAIT1 1
ESTABLISHED 634
SYN_RECV 2
LAST_ACK 1

ESTABLISHED 表示正在通信,TIME_WAIT 表示主动关闭,CLOSE_WAIT 表示被动关闭。

8、讲一下TCP四次挥手

TCP四次挥手用户双方断开连接,TCP四次挥手由任意一方发起,这里假设A主机和B主机:

1、A主动发起释放连接请求,FIN=1,seq=u

2、B收到A的连接释放报文后,立即回复A主机一个ACK报文(ACK=1,ack=u+1,seq=v),表示自己收到了A主机的连接释放报文

3、B主机此时会通知ApplicationA主机要释放连接了,Application执行资源释放代码,完毕后回复A主机连接释放报文,ACK=1,FIN=1,ack=u+1,seq=w

4、A主机回复B主机连接释放报文,ACK=1,ack=w+1,seq=u+1,并且等待2MSL时间后关闭,B主机在收到A主机的ACK报文后也会关闭

9、为什么会有四次挥手

因为B主机收到A主机连接释放报文后不会立即关闭Socket,只能先回复一个ACK报文,告诉A主机你的连接释放请求报文我已经收到了,等到B主机全部发完报文后,B主机才会向A主机发送FIN报文

10、什么是2MSL的等待时间

MSL是TCP报文段的最大生存时间,2MSL是报文段在AB主机之间的往返时间,为了最后的ACK报文能到达B主机,B主机才能正常关闭连接。

如果B主机未收到A主机发的最后的ACK报文,B主机会重发FIN报文,一来一去正好是两个MSL;还有2MSL的等待时间也是为了避免新旧连接混淆,因为经过2MSL,上一次连接中所有的重复包都会消失

11、服务器出现大量CLOSE_WAIT的原因

最有可能的就是资源释放代码有BUG,没有正确发出ACK=1、FIN=1的报文,导致大量连接不能正常关闭,也就是出现大量CLOSE_WAIT的原因

12、服务器出现大量TIME_WAIT的原因

一些爬虫服务器(如果网管在安装的时候没有做内核参数优化的话)上经常会遇到这个问题 ,TIME_WAIT是主动关闭连接的一方保持的状态,对于爬虫服务器来说他本身就是“客户端”,在完成一个爬取任务之后,他就 会发起主动关闭连接,从而进入TIME_WAIT的状态,然后在保持这个状态2MSL(max segment lifetime)时间之后,彻底关闭回收资源。

解决思路很简单,就是让服务器能够快速回收和重用那些TIME_WAIT的资源,vim /etc/sysctl.conf

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
#对于一个新建连接,内核要发送多少个 SYN 连接请求才决定放弃,不应该大于255,默认值是5,对应于180秒左右时间  
net.ipv4.tcp_syn_retries=2
#net.ipv4.tcp_synack_retries=2
#表示当keepalive起用的时候,TCP发送keepalive消息的频度。缺省是2小时,改为300秒
net.ipv4.tcp_keepalive_time=1200
net.ipv4.tcp_orphan_retries=3
#表示如果套接字由本端要求关闭,这个参数决定了它保持在FIN-WAIT-2状态的时间
net.ipv4.tcp_fin_timeout=30
#表示SYN队列的长度,默认为1024,加大队列长度为8192,可以容纳更多等待连接的网络连接数。
net.ipv4.tcp_max_syn_backlog = 4096
#表示开启SYN Cookies。当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭
net.ipv4.tcp_syncookies = 1

#表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭
net.ipv4.tcp_tw_reuse = 1
#表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭
net.ipv4.tcp_tw_recycle = 1

##减少超时前的探测次数
net.ipv4.tcp_keepalive_probes=5
##优化网络设备接收队列
net.core.netdev_max_backlog=3000

修改完之后执行/sbin/sysctl -p让参数生效。

12、TCP和UDP的区别

UDP的主要特点是:
(1)无连接;
(2)尽最大努力交付;不保证可靠交付
(3)面向报文,不对报文拆分或者合并;
(4)无拥塞控制;
(5)支持一对一、一对多、多对一和多对多的交互通信;
(6)首部开销小(只有四个字段:源端口、目的端口、长度、检验和,即8个字节)。

TCP的主要特点是:
(1)面向连接;
(2)每一条TCP连接只能是点对点的(一对一);
(3)提供可靠交付的服务;
(4)提供全双工通信;
(5)面向字节流。

13、GET请求和POST请求的区别

HTTP报文层面:GET将请求信息放在URL、POST放在报文体中。GET请求URL长度受浏览器限制, HTTP协议本身对URL长度并没有做任何规定。

数据层层面:GET符合幂等性和安全性, 反复读取不应该对访问的数据有副作用 ;POST不符合幂等性和安全性

其他层面:GET可以被缓存POST不幂等也就意味着不能随意多次执行,因此也就不能缓存。

GET和POST还有一个重大区别,简单的说:GET产生一个TCP数据包;POST产生两个TCP数据包。
对于GET方式的请求,浏览器会把http header和data一并发送出去,服务器响应200(返回数据); 而对于POST,浏览器先发送header,服务器响应100 continue,浏览器再发送data,服务器响应200 ok(返回数据)。

14、Session的两种实现方式

1、使用Cookie来实现,也就是以SESSIONID为Cookie的Key,以SESSIONID的值为Cookie的Value,每次请求的时候都会通过Cookie机制携带上这个SESSIONID

2、如果客户端禁止使用Cookie,那么就使用URL回写来实现,就在参数 url 中加入 Session ID 信息,然后返回修改后的 url , 通过这种机制,url中保存了sessionId,然后点击URL时又回传到服务器,来维持身份。

15、Cookie和Session的区别

Cookie数据存放在客户的浏览器上,Session数据放在服务器上

Session相对Cookie更安全

如果考虑减轻服务器负担,应该使用Cookie

16、HTTPS真的很安全吗

浏览器默认填充http://,请求需要进行跳转,又被劫持的风险,如果一开始输入的地址的https://… 那么这样还是可以保证安全性的,可以使用HSTS(HTTP Strict Transport Security)优化,目前还未开始推行

17、UDP如何实现可靠传输

UDP要想可靠,就要接收方收到UDP之后回复个确认包,发送方有个机制,收不到确认包就要重新发送,每个包有递增的序号,接收方发现中间丢了包就要发重传请求,当网络太差时候频繁丢包,防止越丢包越重传的恶性循环,要有个发送窗口的限制,发送窗口的大小根据网络传输情况调整,调整算法要有一定自适应性。

恭喜你, 你在应用层重新实现了TCP!

18、ARP地址解析协议,工作原理

《NAT技术与ARP协议-ARP协议》 ARP不是一个单纯的数据链路层的协议,而是一个介于数据链路层和网络层之间的协议。ARP协议的作用:ARP协议建立了主机IP地址和MAC地址的映射关系。其实就是喊话的方式,大家都听见了,但是只有符合IP的主机才会回发自己的MAC地址。

19、 ICMP协议

ICMP是InternetControl Message Protocol,因特网控制报文协议。它是TCP/IP协议族的一个子协议,用于在IP主机、路由器之间传递控制消息。控制消息是指网络通不通、主机是否可达、路由器是否可用等网络本身的消息。这些控制消息虽然并不传输用户数据,但是对于用户数据的传递起着重要的作用。ICMP报文有两种:差错报告报文和询问报文。 详情见《辅助IP的ICMP》

20、TTL是什么?作用是什么?

TTL是指生存时间,简单来说,它表示了数据包在网络中的时间,经过一个路由器后TTL就减一,这样TTL最终会减为0,当TTL为0时,则将数据包丢弃,这样也就是因为两个路由器之间可能形成环,如果没有TTL的限制,则数据包将会在这个环上一直死转,由于有了TTL,最终TTL为0后,则将数据包丢弃。

21、TCP流量控制、拥塞控制

关于TCP的流量控制、拥塞控制见《TCP的高性能机制》,点击链接

22、谈谈OSI七层模型与TCP/IP五层模型

mark

赏

谢谢你请我喝咖啡

支付宝
微信
  • 本文作者: Tim
  • 本文链接: https://zouchanglin.cn/554301047.html
  • 版权声明: 本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 许可协议。转载请注明出处!
  • 计算机网络
  • 计算机网络

扫一扫,分享到微信

解决跨域问题
高效的Linux系统编程环境
  1. 1. 0、讲一下TCP三次握手
  2. 2. 1、seq是固定的吗
  3. 3. 2、三次握手可以携带数据吗
  4. 4. 3、什么是半连接队列
  5. 5. 4、谈谈SYN攻击
  6. 6. 5、第三次握手丢失,会怎样
  7. 7. 6、Linux如何判断受到了SYN攻击
  8. 8. 7、Linux查看网络状态
  9. 9. 8、讲一下TCP四次挥手
  10. 10. 9、为什么会有四次挥手
  11. 11. 10、什么是2MSL的等待时间
  12. 12. 11、服务器出现大量CLOSE_WAIT的原因
  13. 13. 12、服务器出现大量TIME_WAIT的原因
  14. 14. 12、TCP和UDP的区别
  15. 15. 13、GET请求和POST请求的区别
  16. 16. 14、Session的两种实现方式
  17. 17. 15、Cookie和Session的区别
  18. 18. 16、HTTPS真的很安全吗
  19. 19. 17、UDP如何实现可靠传输
  20. 20. 18、ARP地址解析协议,工作原理
  21. 21. 19、 ICMP协议
  22. 22. 20、TTL是什么?作用是什么?
  23. 23. 21、TCP流量控制、拥塞控制
  24. 24. 22、谈谈OSI七层模型与TCP/IP五层模型
© 2017-2021 Tim
本站总访问量次 | 本站访客数人
  • 所有文章
  • 工具

tag:

  • 生活
  • Android
  • 索引
  • MySQL
  • 组件通信
  • Nginx
  • JavaSE
  • JUC
  • JavaWeb
  • 模板引擎
  • 前端
  • Linux
  • 计算机网络
  • Docker
  • C/C++
  • JVM
  • 上传下载
  • JavaEE
  • SpringCloud
  • Golang
  • Gradle
  • 网络安全
  • 非对称加密
  • IDEA
  • SpringBoot
  • Jenkins
  • 字符串
  • vim
  • 存储
  • 文件下载
  • Mac
  • Windows
  • NIO
  • RPC
  • 集群
  • 微服务
  • SSH
  • 配置中心
  • XML
  • Chrome
  • 压力测试
  • Git
  • 博客
  • 概率论
  • 排序算法
  • 分布式
  • 异常处理
  • 文件系统
  • 哈希
  • openCV
  • 栈
  • 回溯
  • SpringCore
  • 流媒体
  • rtmp
  • 面向对象
  • Vue
  • ElementUI
  • 软件工程
  • 异步
  • 自定义UI
  • ORM框架
  • 模块化
  • 交互式
  • Jsoup
  • Http Client
  • LRUCache
  • RabbitMQ
  • 消息通信
  • 服务解耦
  • 负载均衡
  • 权限
  • 多线程
  • 单例模式
  • Protobuf
  • 序列化
  • Python
  • m3u8
  • 堆
  • 二叉树
  • 自定义View
  • 观察者模式
  • 设计模式
  • 线程池
  • 动态扩容
  • 高可用
  • GC
  • ffmpeg
  • SpringMVC
  • REST
  • Redis
  • 缓存中间件
  • UML
  • Maven
  • Netty
  • 高性能网络
  • IPC通信
  • IO
  • Stream
  • 发布订阅
  • SQLite
  • Hash
  • 集合框架
  • 链表
  • Lambda
  • 汇编语言
  • 组件化
  • Router
  • 开发工具

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录(注意不是yilia-plus根目录)执行以下命令:
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置:

      jsonContent:
        meta: false
        pages: false
        posts:
          title: true
          date: true
          path: true
          text: false
          raw: false
          content: false
          slug: false
          updated: false
          comments: false
          link: false
          permalink: false
          excerpt: false
          categories: false
          tags: true
    

  • 思维导图
  • PDF工具
  • 无损放大
  • 代码转图
  • HTTPS证书