Posix API与网络协议栈的实现原理

简介: Posix API与网络协议栈的实现原理


面试中协议栈常问的点

1. TCP三次握手过程?

2. TCP四次挥手过程?

3. 为什么建立连接需要三次握手,而断开 连接需要四次握手?

4. TIME_WAIT状态持续时间及原因

5.大量的time_wait于close_wait

6. 超时重传和快速重传

7. TCP首部长度,有哪些字段

8. TCP在listen时的参数backlog的意义

9. Accept发生在三次握手的哪一步?

10. 三次握手过程中有哪些不安全性

11.TCP与UDP的区别

udp主要用在哪里:

1.大量数据传输,(比如迅雷vip,大量下载的时候其他人会很卡,因为udp没有拥塞控制)

2.实时性。

3.dns协议。(浏览器打开www.baidu.com获取ip地址的过程采用的是udp。

udp的缺点有哪些:

1.不稳定                          

建立连接的过程:

udp不建立连接,没有三次握手,也可以调用connect()函数,udp的这个connect()函数没有发送具体的数据,仅此尝试一下这条链路是不是通的,对方的这个ip地址和端口号有没有存在。如果返回是个正数成功的话,那么接下来调用sendto()成功的概率要比不调用connect()高很多。

tcp在发送数据之前是要调用connect()函数建立连接的,服务器必须要处在listen()的状态才能接收连接。

我们所调用的这些API都是在应用程序里面调用的。三次握手(四次挥手)的过程是发生在TCP/IP协议栈和协议栈之间。这是协议栈帮忙实现的,跟我们的应用程序没有关系。

send()这个函数干的事情就是将数据从用户空间copy到协议栈TCB里面,一个fd对应一个TCB,通过fd,找到对应的TCB。再次调用send()也只是继续copy到协议栈里面的send_buffer里面。 至于这个数据怎么到对方的协议栈里面的,不是应用程序管的,是tcp协议栈自己去做的,就是需要tcp的确认机制,慢启动,拥塞控制...等。

                                 commit_skb()

调用connect()函数的时候,此时应用程序会把本机的ip和port。copy到协议栈里面,协议栈会自己准备一个包(SYN)(TCP头八个状态位里面把SYN状态位置1),然后把这个数据发给对端。服务端会返回一个ACK 和一个SYN。并且保存服务端的一些信息(因为服务端只有一个,客户端可以有n多个) ,当第三次握手来了之后,服务端会拿着这个信息和去半连接队列里面对比有没有这个节点,然后再把这个节点拿到全连接队列里面来(这个节点不是拷贝,是移动)。(进入全连接队列的前提条件是第三次握手过来,并且在半连接队列里面有,这两个条件同时满足,才进入全连接队列)。accept()这个函数只干两件事情,1. 从accept队列里面拿出一个节点,2. 位这个节点分配一个与之对应的fd,然后返回这个fd。(如果此时这个全连接队列里面没有节点,accept会进入条件等待,等待全连接队列里面有节点,此时会进入阻塞状态)。如果此时这个fd被设置为非阻塞fcntl(fd,noblock),此时accept就会立即返回-1。

第三次握手的时候通过什么找到半连接队列里面的对应的节点?  

通过五元组(sip , dip , sport , dport ,porto),这些信息在tcp/ip协议头和ip协议头里面都有。目的ip和目的端口都是一样的,只需要拿sip和sport对比一下就知道了。

半连接队列里面的节点也叫做TCP控制块(TCB)

半连接队列节点的生命周期它有多长?

tcp的(11个状态)状态是存在半连接队列的节点里面的,伴随着连接过程的整个生命周期。

脏数据:  多个客户端同时sendto给一个fd的时候,recvfrom的数据可能会乱序。 一个fd对应一个recvbuffer。   在这个recvbuffer里面无法区分数据是哪个客户端来的。

怎么解决udp并发的问题:                       模拟tcp

1. recvfrom(&addr) 接收到第一帧的信息,拿到他的ip地址和端口号。

2. 新建一个fd,调用sendto(fd ,...) 给对端发。 出现了一个fd对应一个客户端的现象。

如果接收到第一帧包不对的话就返回,然后超时重发。

TCP是如何保证顺序的

TCP的超时重传机制,每发送一个包,会启动一个200ms的定时器。比如当检测到3号包没到的话,将重新发送3号以及后面的所有包。(这也是tcp缺点之一: 确认时间周期长,重传的时候会重传那些即使已经收到的包---重发的次数有点多) ack就是一个数字,可以理解为是多少号包以前的全部收到了。      tcp会延迟发送ack

TCP的超时重传只会在发送方启动一个定时器,对方是不会启动定时器的,如果对方回的这个ACK丢失了,那么也会引起发送方的超时重传。

tcp一开始是慢启动的,最先是指数级增长,到一定程度后线性增长,当线性增长到达最大值之后砍一半,继续线性增长,后面这个过程叫拥塞控制(发包的数量)。

断开连接

调用close、shutdown 、connect、send这四个函数的时候会有一个数据发送的过程

当对端close的时候,epoll里面就会触发EPOLLRDHUP。如果两端都close了,自己也发送出去了FIN并且也收到了ACK,那么此时如果这个fd还在EPOLL里面。那么这一步就会触发EPOLLHUP

大量的time_wait怎么办?

首先是主动调用close(),主动方才有time_wait。如果作为服务方,出现大量的time_wait是不正常的现象(你的服务器代码里面出现了主动调用close的现象)。(先检查你的逻辑看看调用close的地方是不是正常的,如果不是正常的就把业务代码改一下。如果是正常的,可以通过setsockopt(REUSE),设置为重用。当这个TCB设置为重用之后,这个TCP不会被释放,会再次拿来使用。能够在一定限度上去减少time_wait。

time_wait的作用:

保证最后一个fin接收,对端能够收到最后一个ack,当对端发送最后一个fin的时候对端会启动一个定时器,如果ack没有及时收到,fin会进行重发,time_wait的作用就是当有fin过来的时候给对端回ack , 仅此一个作用。

如果没有time_wait:就会丢失最后一个ack,time_wait直接结束了,对应的tcb控制块被释放掉了,对方再发fin过来的时候没有tcb做响应,回不了数据,就会出现对端一直处于last_ack状态一直不会结束。

大量的close_wait怎么办?

当recv返回0,可以判断对端关闭了。此时进入close_wait状态。这时候出现大量的close_wait状态是因为服务端调用close这个过程延迟了。(服务端知道客户端断开连接了,但是在服务端调用close之前可能需要对客户端释放一些信息,还需要向客户端发送一些数据,这个逻辑代码可能有点长,延迟了close的调用)。(还有一些特殊情况就是你在服务端没有调用close)

这种时候就要看看你recv返回0之后你调用close是不是正确的时机。当recv返回0之后应该是立即调用close。然后把业务代码的解析和释放可以抛给另外一个线程,把这个fd(客户端)的信息抛给另外一个线程去释放业务代码。不应该在recv返回0这个流程里面处理。可以做成异步处理。

fin_wait_2状态能不能终止?   (大量fin_wait_2怎么解)

比如现在进入了fin_wait_2状态,等待着对方调用close,但是对方迟迟不调用close。所以此时出现了很多的这种close_wait 和 fin_wait_2。 (答案是没有) 。 当客户端调用完close之后,客户端能做的事情已经做完了,此时需要等待对方调用close。在逻辑代码上面已经没办法处理了。真的要强行禁止,只能kill。  

但是站在客户端的层次,一个连接出现一个fin_wait_2影响不大,再建立一个连接(connect)发送数据这也是OK的。但是这样周而复始就会出现大量的fin_wait_2的状态,当太多的时候只能kill掉或者通知对方处理,否则无解

同时close

当应用层发出关闭命令时,两端均从ESTABLISHED变为FIN _ WAIT_1。

这将导致双方各发送一个 FIN,两个FI N经过网络传送后分别到达另一端。收到FIN后,状态由F I N_WAIT_1变迁到 C L O S I N G,并发送最后的ACK。当收到最后的 ACK时,状态变化为TIME _ WAIT。

网路协议栈

Send缓冲区

send/recv

Udp数据帧

UDP协议

ARP协议

ICMP协议

总结:

服务端:

socket() : 文件系统分配一个fd , 并且给他分配一个TCB。

bind() :为TCB绑定一个本地ip地址和端口号。

listend() :把这个TCB置为一个Listen状态

accept() :为全连接队列里面取出一个节点。并为他分配一个fd

recv () : 从TCB的recvBuffer里面把数据拷贝出来。

send() :把数据copy到fd对应的sendBuffer里面。

close() : 1   准备一个fin包放到sendBuffer里面去,  2 回收fd

剩下的就跟应用程序没关系了。由协议栈决定。

客户端:

connect() : 准备一个SYN包交给协议栈发出去,等待三次握手完成之后再返回。

连接不成功会置错误值。

相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
目录
相关文章
|
22天前
|
机器学习/深度学习 存储 算法
神经网络分类算法原理详解
神经网络分类算法原理详解
44 0
|
1月前
|
弹性计算 负载均衡 网络协议
这种情况可能是由于阿里云的API服务出现了短暂的故障或者网络波动导致的
【2月更文挑战第20天】这种情况可能是由于阿里云的API服务出现了短暂的故障或者网络波动导致的
65 1
|
13天前
|
运维 Kubernetes Cloud Native
探索Kubernetes的大二层网络:原理、优势与挑战🚀
在云原生领域,Kubernetes (K8s) 已经成为容器编排的事实标准☁️📦。为了支撑其灵活的服务发现和负载均衡🔍🔄,K8s采用了大二层网络的设计理念🕸️。本文将深入探讨大二层网络的工作原理、带来的好处✨,以及面临的挑战和解决方案❗🛠️。
探索Kubernetes的大二层网络:原理、优势与挑战🚀
|
1月前
|
网络协议 Linux API
Linux网络编程:shutdown() 与 close() 函数详解:剖析 shutdown()、close() 函数的实现原理、参数说明和使用技巧
Linux网络编程:shutdown() 与 close() 函数详解:剖析 shutdown()、close() 函数的实现原理、参数说明和使用技巧
69 0
|
2天前
|
安全 数据建模 网络安全
深入理解SSL数字证书:定义、工作原理与网络安全的重要性
本文阐述了SSL数字证书在网络安全中的关键作用,定义了其作为验证服务器身份的数字凭证,基于PKI体系保障数据传输安全。文章介绍了三种类型的证书,包括DV、OV和EV,适用于不同安全需求的网站。获取和安装证书涉及向证书颁发机构申请并部署到服务器。在网络安全挑战下,正确使用和管理SSL证书对于保护用户数据和提升信任度至关重要。
|
8天前
|
安全 网络协议 网络安全
网络原理(5)--HTTPS是如何进行加密的
网络原理(5)--HTTPS是如何进行加密的
5 0
|
8天前
|
存储 JSON 前端开发
网络原理(4)HTTP协议(下)
网络原理(4)HTTP协议
24 0
|
12天前
|
传感器 监控 安全
|
22天前
|
缓存 网络协议 数据库连接
【底层服务/编程功底系列】「网络通信体系」深入探索和分析TCP协议的运输连接管理的核心原理和技术要点
【底层服务/编程功底系列】「网络通信体系」深入探索和分析TCP协议的运输连接管理的核心原理和技术要点
21 0
|
30天前
|
存储 安全 网络安全
网络技术基础(20)——AAA原理与配置
【3月更文挑战第6天】华为设备的AAA框架实现网络安全管理,包括认证、授权、计费三要素,常使用RADIUS协议。用户、NAS(Network Access Server)和AAA服务器构成基本架构。认证方式有不认证、本地认证和远端认证,授权方式包括不授权、本地授权和远端授权,计费则为不计费和远端计费。RADIUS作为分布式协议,处理认证、计费和授权。常见应用场景如SSH登录,配置涉及创建认证方案、用户及服务类型。实验配置示例展示了SSH登录的AAA验证过程。