zeus_abc的博客

网卡发送和接收缓冲区是实际有空间，还是一个数字而已？    这个只是一个逻辑值,并不实际分配内存    这是网卡的级别的限制,超过了阀值,数据就不收发了 网卡的发送和接收缓冲区是所有连接共享？    是的,也有连接级别的发送和接收缓冲区的大小限制    通过sock_setopt来设置,这是tcp,udp中的队列的大小  网卡驱动初始化的时候,会从内核中割出一块

go入门必备

go反射机制的摸索

go入门

1、EBADF---找不到对应的文件对象2、连接并未建立,等待直到进入TCPF_ESTABLISHED或者TCPF_CLOSE_WAIT   1、ERESTARTSYS ---当前套接字上有事件,调度时间到了   2、EINTR--当前套接字上有事件,被中断   3、EPIPE --连接状体没不是TCPF_SYN_SENT | TCPF_SYN_RECV,直接返回   4、EA

1、ENOTCONN ---当前状态为TCP_LISTEN2、flags为带外数据tcp_recv_urg   ENOTCONN ---当前状态为TCP_CLOSE   EINVAL   ---TCP_URG_READ   EFAULT   ---拷贝失败   EAGIN    ---TCP_URG_NOTYET     返回len  ---TCP_URG_VALID3

选择重传与分片的概念    选择重传不是指分片中的某个部分丢了,选择某个分片  选择重传的粒度不是分片而是滑动窗口中的单元TCP协议中的seq表示的是字节数还是包序号？   seq其实就是连接的字节数TCP中发送数据后,基本就是已经异步过程了   数据仅仅是拷贝到了发送队列中,之后的数据发送就是交给ip层了,需要做路由选择    数据发送tcp_sendmsg中

注册软中断static int __init net_dev_init(void) { ...... open_softirq(NET_TX_SOFTIRQ, net_tx_action); open_softirq(NET_RX_SOFTIRQ, net_rx_action); ......}static void net_tx_acti

Qdisc中的实现方式大致如下struct Qdisc{ int (*enqueue)(struct sk_buff *skb, struct Qdisc *dev); struct sk_buff * (*dequeue)(struct Qdisc *dev); unsigned flags; int padded; struct Qdisc_ops *ops; s

数据发送tcp_write_xmit(){  while ((skb = tcp_send_head(sk)))   {     tcp_event_new_data_sent(sk, skb);//重新获取首部  }}数据发送经过ip层路由和邻居协议后发送队列关联了Qdiscnet/core/Dev.cint dev_queue_xmit(struct s

中断下半部处理   中断下半部将网卡中的DMA-ring中的skb取出来,经过ip层处理,主要是netfilter   最后决定是否传递到本地传输层   如果交给本地传输层ip的最后处理ip_local_deliver_finish中断的下半部的结束位置是哪里? 何时出中断上下文?   中断下半部的结束是把这个从DMA-ring中的skb找到归宿(传输层的队列或者转发出去)

查看当前正在使用的拥塞算法   sysctl net.ipv4.tcp_available_congestion_control   /proc/sys/net/ipv4/tcp_congestion_control 常见的拥塞算法  cubic(RTT隔离,但有流量突发)  reno  hybla  vegas  illinois  hstcp(RTT不公平性

epoll工作机理       epoll_wait检查epoll句柄中的rdllist不为空退出循环       遍历所有的epitem,把各种ready的fd收集起来返回这里有一个疑问       谁来影响rdllist不为空,一般的说法是文件的fd的状态发生改变,就能有某个方法将fd加入到rdllist中,并通知调用epoll_wait的进程        答案是

结论     tcp客户端connect发起之后,协议栈就会发送SYN给服务器,协议栈收到来自服务器的响应后,发出Ack后,就进入了established   tcp服务器在收到SYN后,发送SYN+ACK后就进入SYN_RECVD,再次收到客户端的Ack时,也进入established   established状态连接的双方进入的时机是有先后的,客户端是先进入的,服务器是后进入的

半连接   未完成3次握手,但是已经发送了SYN,Peer也发了SYN+ACK,但是不再发送ACK半开连接   一方已经关闭连接,另一方尚不知道    比如:       客户端崩溃、死机,服务器怎么能知道呢       使用SO_KEEPALIVE,超时最长是2小时       故此应用层来实现KEEP_ALIVE,来确定对方的存活与否    客户端此时的

redis