计算机网络面试题整顿
咱们来回顾一下上次分享到的mongodb
的装置和应用
mongodb
的介绍mongodb
如何装置mongodb
如何简略应用- GO 如何操作
mongodb
要是对于mongodb
还有点趣味的话,能够查看文章 一文便知 GO 中mongodb 的装置与应用
明天咱们来看点面试题
计算机网络面试题
网络字节序:
大端模式,低地址存高字节
本地字节序:
小端模式,低地址存低字节
三次握手
- 被动发动连接端,发送SYN标记为,申请建设连贯。携带序号,数据字节大小(0),滑动窗口大小
- 被动承受端,发送
ACK
应答,SYN标记。携带序号,数据字节大小(0),确认序号,滑动窗口大小 - 被动发动连接端,发送
ACK
应答,携带确认序号
四次挥手
- 被动敞开连接端,发送FIN,
- 被动敞开端,发送
ACK
。 -- 半敞开 - 被动敞开端,发送FIN
- 被动敞开端,发送
ACK
应答 -- 连贯全副敞开
TCP第三次握手失败会呈现什么
如果此时ACK
在网络中失落,过了超时计时器后,那么Server端会从新发送SYN+ACK
包
重传次数依据/proc/sys/net/ipv4/tcp_synack_retries
来指定,默认是 5
次
如果重传指定次数到了后,依然未收到ACK
应答,那么一段时间后,Server主动敞开这个连贯
然而Client认为这个连贯曾经建设,如果Client
端向Server
写数据,Server端将以RST
包响应,方能感知到Server
的谬误。
当失败时服务器并不会重传ack
报文,而是间接发送RTS
报文段,进入CLOSED
状态
这样做的目标是为了避免SYN
洪泛攻打
长连贯和短连贯区别和优缺点
长连贯:连贯->传输数据->放弃连贯 -> 传输数据-> ………..->直到一方敞开连贯,多是客户端敞开连贯
长连贯指建设SOCKET连贯后不论是否应用都放弃连贯,但安全性较差。
- 长处
长连贯能够省去较多的tcp建设/敞开
的操作,缩小节约,节省时间,对于频繁申请资源的客户,较实用于长连贯;
- 毛病
随着客户的越来越多,server早晚会有扛不住的一天,这时须要采取一些策略,如敞开一些长时间不读写操作的连贯,这样能够防止一些歹意连贯导致server端服务受损,如果条件再容许,就能够以客户端为颗粒度,限度每个客户端的最大连接数
短连贯
连贯->传输数据->敞开连贯
比方HTTP是无状态的的短链接,浏览器和服务器每进行一次HTTP操作,就建设一次连贯,但工作完结就中断连贯。
- 长处:
短连贯对于服务器来说较为简单,存在的连贯都是有用的连贯,不须要额定的管制
- 毛病:
客户端连贯频繁,会在tcp
的建设和敞开上浪费时间。
滑动窗口
发送给对端连贯,本段的缓冲区实时大小,保证数据不会失落。
网络通信中 read 函数的返回值:
- = 0
表明对端曾经敞开连贯
- = -1
判断errno
的状况
- errno == EAGAIN|EWOULDBLOCK
设置了非阻塞的形式,读的时候,数据还没有达到
- errno == EINTR
被信号中断
- errno == 其余状况
异样
查看端口号
netstat -antp
端口复用设置
int opt = 1; setsockopt(fd,SOL_SOCKET,SO_REUSEADDR,(void *)&opt,sizeof(opt));
半敞开(FIN_WAIT_2)
终止一个连贯要通过 4次 握手
这由TCP的半敞开(half-close)
造成的
CLOSE_WAIT
状态的问题状况
父过程关上了socket
,而后用派生子过程来解决业务,父过程持续对网络申请进行监听,永远不会终止
客户端发FIN
过去的时候,解决业务的子过程的read返回0,子过程发现对端曾经敞开了,间接调用close()对本端进行敞开
实际上,仅仅使socket
的援用计数减1,socket
并没敞开。从而导致系统中又多了一个CLOSE_WAIT
的socket。。。
如何防止上述情况?
子过程的敞开解决应该是这样的:
shutdown(sockfd, SHUT_RDWR);
close(sockfd);
这样解决,服务器的FIN会被收回,socket进入LAST_ACK
状态,期待最初的ACK
到来,就能进入初始状态CLOSED
shutdown()的函数阐明
linux
零碎下应用 shutdown
零碎调用来管制socket的敞开形式
int shutdown(int sockfd,int how);
参数 how
容许为shutdown
操作抉择以下几种形式:
- SHUT_RD
敞开连贯的读端。也就是该套接字不再承受数据,任何以后在套接字承受缓冲区的数据将被抛弃。过程将不能对该套接字收回任何读操作。对TCP套接字该调用之后承受到的任何数据将被确认而后被抛弃。
- SHUT_WR
敞开连贯的写端。
- SHUT_RDWR
相当于调用shutdown
两次:首先是以SHUT_RD,而后以SHUT_WR
留神:
在多过程中如果一个过程中shutdown(sfd, SHUT_RDWR)
后其它的过程将无奈进行通信,如果一个过程close(sfd)
将不会影响到其它过程
2MSL
时长 TIME_WAIT
肯定呈现在被动敞开的一端,保障最初一个ACK
对端可能收到。
1.TTL
是什么?
TTL是 Time To Live的缩写
该字段指定IP
包被路由器抛弃之前容许通过的最大网段数量。
TTL是IPv4
包头的一个8 bit
字段。
2. TTL的作用
TTL的作用是限度IP
数据包在计算机网络中的存在的工夫。
TTL的最大值是255,TTL的一个推荐值是64
3.TTL
原理
尽管TTL
从字面上翻译,是能够存活的工夫,但实际上TTL是IP
数据包在计算机网络中能够转发的最大跳数。
TTL
字段由IP
数据包的发送者设置,在IP
数据包从源到目标的整个转发门路上
每通过一个路由器,路由器都会批改这个TTL
字段值,具体的做法是把该TTL的值减1,而后再将IP
包转发进来。
如果在IP
包达到目标IP
之前,TTL缩小为0,路由器将会抛弃收到的TTL=0的IP
`包并向
IP包的发送者发送
ICMP` 发送超时报文。
c/s 模型和 b/s 模型的优缺点
c/s模型
长处:
C/S的最大长处是可能实现简单的利用结构,安全性高,数据传输速度快。
- 构造简略。
- 反对分布式、并发环境。无效进步资源的利用率和共享水平。
- 服务器集中管理资源,有利于权限管制和系统安全。
- 可扩展性较好。客户和服务器均可独自地降级
毛病:
- 不易部署(客户端逐个装置、挑平台)
- 保护艰难(客户端需注意更新)
- 开发工作量大
工作过程
- 关上一个通信通道,告知服务器过程所在主机将在某一端口上承受客户申请
- 期待客户的申请达到该端口
- 服务器接管到服务申请,解决该申请并发送应答
- 返回至第2步,期待并解决另一个客户的申请
- 敞开服务器
b/s
模型
长处:
B/S
最大的长处就是能够在任何中央进行操作而不必装置任何专门的软件,只有有一台能上网的电脑就能应用
客户端零装置、零保护。零碎的扩大非常容易。
分布式、易扩大、共享性强
相比拟传统的C/S
的劣势:
- 1.易部署(各平台自带通用浏览器)
- 2.容易保护(服务器端扭转网页内容可实现所有用户同步更新)
- 3.页面动静刷新,响应速度明显降低。
- 开发工作量小
毛病:
- 不能缓存大量数据
工作过程
- 用户通过浏览器向
Web
服务器提出HTTP
申请。 Web
服务器依据浏览器申请调出相应文件,对相应文件不做解决或加以解释执行后,将纯客户端HTML
代码后果返回给浏览器。- 浏览器接管到
Web
服务器发回的页面内容(纯HTML
代码),显示给用户。
ping的过程和ICMP
协定
过程例子
- A电脑(192.168.2.135)发动ping申请,ping 192.168.2.179
- A电脑播送发动
ARP
申请,查问 192.168.2.179的MAC地址。 - B电脑应答
ARP
申请,向A电脑发动单向应答,通知A电脑本人的MAC地址为90:A4:DE:C2:DF:FE
- 晓得了MAC地址后,开始进行真正的ping申请,因为B电脑能够依据A电脑发送的申请晓得源MAC地址,所有就能够依据源MAC地址进行响应了。
ping命令是依靠于ICMP
协定的,ICMP
协定的存在就是为了更高效的转发IP
数据报和进步交付胜利的机会。
ping命令除了依靠于ICMP
,在局域网下还要借助于ARP
协定,ARP
协定能依据IP
地址查出计算机MAC地址。
ARP
是有缓存的,为了保障ARP
的准确性,计算机会更新ARP
缓存。
ICMP
ICMP
是(Internet Control Message Protocol)Internet管制报文协定。
ICMP协定
是一种面向无连贯的协定,它是TCP/IP协定族的一个子协定,用于在IP主机、路由器之间传递管制音讯。ICMP是一个网络层协定。
次要性能次要有:
- 确认
IP
包是否胜利达到指标地址 - 告诉在发送过程中
IP
包被抛弃的起因
总结
- 计算机网络的三次握手,四次挥手
- TCP 第三次握手失败会呈现什么
- 长连贯和短连贯的优缺点
- 滑动创后
- 网络通信中的
read
函数 - 什么是半敞开
- C/S 模型 和 B/S 模型
ICMP
敌人们,写作不易
你的反对和激励,是我保持分享,提高质量的能源
好了,本次就到这里
技术是凋谢的,咱们的心态,更应是凋谢的。拥抱变动,背阴而生,致力向前行。
我是小魔童哪吒,欢送点赞关注珍藏,下次见~