![](https://img-blog.csdnimg.cn/20201014180756780.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
TCP 源码浅读
文章平均质量分 64
尖笔尖
超人不会飞
展开
-
TCP半连接和全连接队列
在 linux 4.18 这个版本中,并不存在所谓的 半连接队列,表示半连接状态的 requst_sock 保存在全局的 ehash 中, 具体结构可以参考文章 TCP源码浅读(1)数据结构,而且它的状态也不是 SYN_RECV,是 NEW_SYN_RECV。这个变化是 linux 4.4 以后产生的,可以阅读下这篇文章 TCP_NEW_SYN_RECV。原创 2022-05-29 08:41:44 · 1563 阅读 · 0 评论 -
TCP源码浅读(6)三次握手-被动方接收ACK
1、首先查找 sock,会在 ehash 中找到代表半连接的 request_sock,它处于 TCP_NEW_SYN_RECV 状态;2、根据 request_sock 关联到 inet_listen_hashbucket 监听该端口的 tcp_sock (TCP_LISTEN);3、调用子流程 tcp_check_req 对 ACK 包做合法性检查,检查通过后,创建一个新的 tcp_sock ,用来表示和客户端的全连接;4、对新的 tcp_sock 进一步处理。原创 2022-05-14 10:43:21 · 408 阅读 · 0 评论 -
TCP源码浅读(5)三次握手-主动方接收SYN+ACK
主动方调用 connect 函数向被动方发起第一次握手后一直处于阻塞状态,直到收到被动方的响应,即第二次握手,主动方才可以继续接下来的处理。原创 2022-05-08 10:56:55 · 850 阅读 · 0 评论 -
TCP源码浅读(4)三次握手-被动方接收SYN
版本:linux 4.18.1作为学习笔记,只讨论常规的三次握手过程。服务端调用 listen 函数后一直处于 TCP_LISTEN 状态,等待客户端的连接请求;上一节我们分析了第一握手,客户端发送了 SYN 包,现在我们来看下服务端接收 SYN 包后的处理过程。// net/ipv4/tcp_ipv4.cint tcp_v4_rcv(struct sk_buff *skb){ struct sock *sk; // 从 tcp_hashinfo 中的各种 has原创 2022-05-04 21:06:50 · 1492 阅读 · 0 评论 -
TCP源码浅读(3)三次握手-主动方发送SYN
客户端调用 connect() 函数向服务端发起连接请求,经典的三次握手就是从这个时刻开启的。我们按照三次握手的流程来梳理。第一次握手,客户端发送 SYN 包。第一次握手主要流程:1、设置 sock 状态为 SYN_SENT;2、绑定端口,将 sock 加入到 bhash 和 ehash 中;3、构造 SYN 包,发送给服务端。原创 2022-05-03 21:12:29 · 1744 阅读 · 0 评论 -
TCP源码浅读(2)服务端 bind & listen
bind() 函数主要流程:首先根据 端口号 计算一个 hash 值,然后通过这个 hash 值在定位到 inet_bind_hashbucket 某个 slot;定位到 slot 后,要遍历它指向的整个链表,看这个端口是否已经存在:如果端口不存在,就新建一个 inet_bind_bucket ,链入该 slot;如果端口已经存在,则要检查是否已经有连接使用了该端口:如果已经有连接使用,则报错(不考虑端口重用);执行到这里,已经有一个 inet_bind_bucket 表示这个端口了原创 2022-05-02 21:43:16 · 1398 阅读 · 0 评论 -
TCP源码浅读(1)数据结构
版本:linux 4.18.1作为学习笔记,只讨论常规的三次握手过程。全局连接信息 inet_hashinfolinux 通过一个全局的 inet_hashinfo 类型的对象 tcp_hashinfo 来管理所有 tcp 连接信息。在 inet_hashinfo 类型中,又包含四个 hashtable 分别管理不同状态下的 sock。// linux-4.18.1/include/net/inet_hashtables.hstruct inet_hashinfo { /原创 2022-05-01 23:30:05 · 927 阅读 · 0 评论