Linux 以本地时钟计数（jiffies）作为时间戳的值，不同的增长时间会有不同的问题： 如果时钟计数加 1 需要1ms，则需要约 24.8 天才能回绕一半，只要报文的生存时间小于这个值的话判断新旧数据就不会出错...这样的话会频繁有包越过 PAWS 检查，从而使得旧包混入数据中的概率大大增加； Linux 在 PAWS 检查做了一个特殊处理，如果一个 TCP 连接连续 24 天不收发数据则在接收第一个包时基于时间戳的...悲观锁是修改共享数据前，都要先加锁，防止竞争。...CAS 是乐观锁没错，但是 CAS 和自旋锁不同之处，自旋锁基于 CAS 加了while 或者睡眠 CPU 的操作而产生自旋的效果，加锁失败会忙等待直到拿到锁，自旋锁是要需要事先拿到锁才能修改数据的，所以算悲观锁...翻译一下就是： 在 Linux 下，select() 可能会将套接字文件描述符报告为“准备好读取”，但随后会出现读取块。例如，当数据到达但检查时校验和错误并被丢弃时，可能会发生这种情况。
，但实际上服务器有可能立刻收到报文，即proxy_upload_rate未生效或者不可控！...基于字节的限速实现原理 首先，我们要明确上例属于Nginx中的哪种限速。...其具体作用原理为：作为接收端的Nginx所在服务器上，会有一个接收缓冲区，比如Linux中的tcp_rmem： net.ipv4.tcp_rmem = 4096 131072 6291456 tcp_rmem...，Nginx使用了含有64个元素的数组cached_time循环复用保存时间，这样读时间时就省去了加锁操作，只在更新时才会加锁并通过变更slot的值移动循环数组： #define NGX_TIME_SLOTS...所以，我们在验证或者设计测试场景时，需要将上述2个因素都纳入考虑。同时，在Nginx更新版本时，综合评估Nginx源码设计的变动，就能更准确的掌握限速的要理。
当有一方要关闭连接时，会发送指令告知对方，我要关闭连接了。这时对方会回一个ACK，此时一个方向的连接关闭。...因为 TCP 报文基于是 IP 协议的，而 IP 头中有一个 TTL 字段，是 IP 数据报可以经过的最大路由数，每经过一个处理他的路由器此值就减 1，当此值为 0 则数据报将被丢弃，同时发送 ICMP...注意：在 Linux 系统里 2MSL 默认是 60 秒，那么一个 MSL 也就是 30 秒。Linux 系统停留在 TIME_WAIT 的时间为固定的 60 秒。...TCP 延迟确认的策略： 当有响应数据要发送时，ACK 会随着响应数据一起立刻发送给对方 当没有响应数据要发送时，ACK 将会延迟一段时间，以等待是否有响应数据可以一起发送（很明显，上述实例就命中了这种情况...并发编程》：第3章 助于线程安全的三剑客：final & volatile & 线程封闭 一文读懂《Java并发编程实战》：第2章 影响线程安全性的原子性和加锁机制 一文读懂《Java并发编程实战》：
在这个方法中，每一个处理器核心的负载可能无法做到均衡， 因为网络数据流中的服务对象的数量以及每个服务对象的网络流 量会随着时间变化。当一个处理器核心过载时，报文因无法被及时接收而丢弃。...轻量化锁限速方案：当多个处理器核心同时对一条网络数据流做限速时，可能存在多个核心同时对同一令牌桶加锁以使某个核心获得令牌桶的所有权，随之产生的“锁”竞争是导致性能下降的主要原因。...在处理同等数量的报文时，轻量化锁的方案对令牌桶加锁的次数明显 低于传统的单一全局令牌桶方案。因此，随着处理器核心数量的增加，轻量化锁限速方案能够在一定程度上减少“锁”竞争，而获得较好的性能。...负载均衡要解决的是因为待处理数据在处理器核心之间分发不均匀，导致的处理器核心负载不均衡的问题。...，当有多条网络数据流时，流量能够较为均匀地分散到各个处理器核心，确保处理器中多个核心的负载均衡。
BPF：柏克莱报文过滤器，一种通过指定的规则快速匹配过滤报文的接口。 perf：linux自带的一种性能分析工具。 背景 TGW是一套实现多网接入的负载均衡系统，为腾讯业务提供着外网接入服务。...瓶颈 请输入标题 abcdefg 做性能优化，首先要分析瓶颈： 1.规则表、连接表等都是多核间的共享资源，读写都加锁，容易造成较大cache-misses。...[1504749452882_4885_1504749453145.jpg] 解决方案 做完瓶颈分析，就来思考解决方案： 1.要消除共享资源加锁，首先想到的方案是无锁化，每个处理报文的核都能自己维护一份资源...2.要消除TLB-misses，则可以采用hugepage，使用2M甚至1G的页面。...原因主要有2点： （1）netmap仍然采用中断，当pps高时，中断容易打断本来正在处理报文的CPU工作，影响吞吐；而DPDK默认采用轮询，CPU自己判断网卡队列是否有报文了，不打断CPU工作。
现在多个用户要发数据，也就是多个用户线程需要写同一个socket_fd。 那么，socket是并发安全的吗？能让这多个线程同时并发写吗？...并发写到加锁队列后由一个线程处理 于是在gateway层，多个用户线程同时写消息时，会去争抢某个socket_fd对应的队列，抢到锁之后就写数据到队列。...并发读socket_fd导致的数据异常 解决方案还是跟读的时候一样，读socket的只能有一个线程，读到了消息之后塞到加锁队列中，再将消息分开给到GameServer的多线程用户逻辑模块中去做处理。...所以我们直接关注另外一个分支，也就是不加锁直接发消息。 那是不是说明走了不加锁的分支时，udp发消息并不是线程安全的？ 其实。还是线程安全的，不用lock_sock(sk)加锁，单纯是因为没必要。...但UDP就不同，UDP 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。 无论应用层交给 UDP 多长的报文，UDP 都照样发送，即一次发送一个报文。
现在多个用户要发数据，也就是多个用户线程需要写同一个socket_fd。 那么，socket是并发安全的吗？能让这多个线程同时并发写吗？...并发写到加锁队列后由一个线程处理 于是在 gateway 层，多个用户线程同时写消息时，会去争抢某个 socket_fd 对应的队列，抢到锁之后就写数据到队列。...并发读socket_fd导致的数据异常 解决方案还是跟读的时候一样，读 socket 的只能有一个线程，读到了消息之后塞到加锁队列中，再将消息分开给到 GameServer 的多线程用户逻辑模块中去做处理...所以我们直接关注另外一个分支，也就是不加锁直接发消息。 那是不是说明走了不加锁的分支时，udp发消息并不是线程安全的？ 其实。还是线程安全的，不用lock_sock(sk)加锁，单纯是因为没必要。...但 UDP 就不同，UDP 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。 无论应用层交给 UDP 多长的报文，UDP 都照样发送，即一次发送一个报文。
是文件级别的操作，第一个主机写数据时会施加锁，第二个主机就不能写。性能要比DAS差。...LVS:Linux virtual server lvs工作于内核的tcp/ip协议栈的input链，不能和iptables同时工作。...当客户端请求报文到达调度器时ip报文首部是CIP|VIP,从prerouting送至input发现为集群服务后，将报文转发至forward经postrouting向后转发，此时ip首部变为CIP|RIP1...当请求报文发送至集群网络时ip报文首部为CIP|VIP，这时因为RS的VIP被隐藏起来了，所以只有调度器响应，而位于input链的策略发现是集群服务时，它不会拆解ip首部，而是把mac首部拆了，封装mac...当请求报文发送到调度器时，ip报文首部为CIP|VIP,调度器发现是集群服务想外转发时在CIP|VIP前面封装一层首部DIP|RIP,RS接受报文并且拆分外面的首部后发现目标地址的确为自己，便开始响应并直接经过路由设备回传给客户端
异步 IO + 直接 IO：高并发场景处理大文件时，应当使用异步 IO+直接 IO 来替换零拷贝技术。...处理基于 TCP 的应用层协议时，一个请求的处理代码必须被拆分到多个回调函数中，由异步框架在相应的事件生成时调用它们。弊端：代码书写难度大，易出错。 3、使用协程，协程可看作用户态的线程。...当取不到锁时，互斥锁用“线程切换”来面对，自旋锁则用“忙等待”来面对。 自旋锁：自旋锁比互斥锁快得多，它通过 CPU 提供的 CAS 函数在用户态代码中完成加锁与解锁操作。...当被动方发送 FIN 报文后，连接就进入 LAST_ACK 状态，在未等来 ACK 时，会在 tcp_orphan_retries 参数的控制下重发 FIN 报文。...Linux 高版本支持 BBR 算法，可以通过 tcp_congestion_control 配置更改拥塞控制算法。
在需要加锁的地方，选择粒度最小的锁。第二点，使用一些高性能的锁，比如读写锁，自旋锁。这个要根据具体的应用场景来选择。...比如在业务第一次触发时，开启相应线程，之后就不需要再关闭了。对于线程池的使用，要选择合理的线程个数。线程太小，无法发挥处理器的多核优势；线程太多，系统会消耗很多性能在线程切换上。...一般来说，线程的数量是处理器核心数量的两倍 4....即做到在每次交互中，处理更多的事情。比如我们自己实现的流媒体服务器，刚开始点播流的时候，要发一些信令报文。之前我们需要三次交互，才能开始发流，后来通过消息合并，节省了一步。...不要小看这一小步，在网络不好的情况下，可能就会减少很多点播时延
nsim配置时，会将带宽转化为每个worker所存储的最大缓存区的存储报文的个数，超过之后就会丢弃。 下面是nsim配置延迟25ms，带宽是10mbps,报文长度1500字节。...先计算每s字节长度：0.025 * 10*1000*1000/8 = 32000；每个报文长度时1500字节，32000/1500 = 21个报文。...目前为了避免加锁，worker wheel 使用的缓存区是基于worker的。 延迟是怎么实现的？...我们以上一节的流程图来说明一下，是在nsim-output-feature节点中，根据配置参数对报文进行处理，将需要延迟的报文记录需要延迟的时间。...保序处理就比较简单了？就是把需要乱序的报文在nsim-output节点直接发送出去，不需要经过网络模拟器调度。如下图所示我们发现有ping回应报文未进行延迟处理。可能就是reorder导致的。
Server端接到FIN报文后，意思是说"我Client端没有数据要发给你了"，但是如果你还有数据没有发送完成，则不必急着关闭Socket，可以继续发送数据。...Client端收到FIN报文后，"就知道可以关闭连接了，但是他还是不相信网络，怕Server端不知道要关闭，所以发送ACK后进入TIME_WAIT状态，如果Server端没有收到ACK则可以重传。...线程有自己的堆栈和局部变量，但线程之间没有单独的地址空间，一个线程死掉就等于整个进程死掉，所以多进程的程序要比多线程的程序健壮，但在进程切换时，耗费资源较大，效率要差一些。...然后把处理机分配给就绪队列中新的队首进程，同时也让它执行一个时间片。这样就可以保证就绪队列中的所有进程，在一给定的时间内，均能获得一时间片处理机执行时间。...那么当检测出死锁时，这些线程该做些什么呢？ 一个可行的做法是释放所有锁，回退，并且等待一段随机的时间后重试。这个和简单的加锁超时类似，不一样的是只有死锁已经发生了才回退，而不会是因为加锁的请求超时了。
除了上面的几个信息外，剩下的就是一些句柄了，当游戏房间中胜负已分时，我们要更新数据库中两个用户的信息，所以还需要数据管理模块的句柄，在用户发起聊天或下棋请求时，我们要判断用户此时是否在线，同时还要将请求处理后的响应广播给房间中的所有用户...所以只要涉及到可能产生线程安全问题的成员变量，对这种变量的操作我们就都需要进行加锁保护！ 虽然一个项目中可能处处要进行加锁，这会导致服务器的效率会降低一些，但服务器稳定才是最重要的！...在处理请求字段这里我们需要先了解一下前后端报文格式的设计，因为只有知道了前后端通信的报文格式的协议之后，我们才能解析请求报文，从而判断请求类型是什么，进而做出相应的业务处理，这样的协议一定要在项目实现前双方都确定好...，因为这样的通信报文协议一换，前后端交互的报文格式都需要更改，那代码的改动量就会变得非常大，所以一定要提前定制好通信时，报文的格式是什么。...下棋请求的字段要包括下棋的行和列，以及下棋用户的uid，还有optype为"put_chess"等。 当下棋失败时要组织好响应，表明下棋失败的具体原因是什么。
❝ Linux设计为硬中断在哪个CPU上被响应，那么软中断也是在这个 CPU 上处理的。...他提供了一种免加锁的方式去解决数据竞争问题。同时也可以避免频繁的申请/释放内存，避免内存碎片的产生。...再添加报文协议头时，也会同时对 __u16 transport_header; //指向传输层协议首部的起始。 __u16 network_header; //指向网络层协议首部的开始。...赋予对应的值 接收数据时sk_buff变化 由于直接移动指针比复制数据更加高效，所以当数据报文从下往上传递时，只需要移动对应指针就可以丢弃上一层的协议头。...例如：报文从L2(数据链路层)->L3(IP层)时，只需要移动data指针就可以丢弃数据链路层的协议头，更加高效。
Linux内核实现版本受限于网卡的中断收包模式以及二三层锁的开销，系统经过调优后的转发能力单台QPS在十万级别。...管理线程负责处理经过内核的报文、进程间通信的报文等，同时将配置下发给各个业务线程，既每个业务线程都拥有一份配置。业务线程有多个线程，包括负载均衡业务的处理、安全防护和会话管理等。...然后对dpdk的rss hash进行了修改，保证业务报文（非kni ip）在rss hash队列时，从1～N中选择。逻辑流程如下图所示： ?...传统的实现方式，对于配置的下发，都是要进行加锁处理的。这势必会影响其它流量的性能。...会话无锁实现 四层负载的新建和并发能力，直接和会话的创建和查找是否加锁有直接关系。如果一个会话只有一个core来处理，即可实现无锁，但是多核处理器下如何保证上下行流量都能落到同一个core呢？
buffer 中读取报文进行处理，执行 IP 和 TCP/UDP 层的逻辑，最后把报文放到应用程序的 socket buffer 中 应用程序从 socket buffer 中读取报文进行处理 图片....之所以没有分析发送数据流程，一是因为发送流程和接收类似，只是方向相反；另外发送流程报文丢失的概率比接收小，只有在应用程序发送的报文速率大于内核和网卡处理速率时才会发生。...，没有时间处理缓存中的 UDP 报文。...另外一个因素是应用读取 buffer 中报文的速度，对于应用程序来说，处理报文应该采取异步的方式 包丢在什么地方 想要详细了解 linux 系统在执行哪个函数时丢包的话，可以使用 dropwatch 工具...buffer size 来降低丢包的概率 应用程序在处理 UDP 报文时，要采用异步方式，在两次接收报文之间不要有太多的处理逻辑
*/ Instance; } 7.学过操作系统吗（学过） 8.讲讲操作系统进程调度（Linux有单独的调度器线程，讲了Linux的CFS完全公平调度算法，还讲了《linux内核设计与实现》老版本的linux...buddy system和slab分配器） 推荐阅读：https://www.cnblogs.com/CareySon/archive/2012/04/25/2470063.html 10.怎么保证线程安全（加锁...） 11.linux有哪些锁 mutexlock, spinlock, semaphore信号量，以及他们对应的读写锁 12.除了加锁还有什么保证线程安全的方式吗？...（不清楚) 客户端宕机后服务端由于得不到回应，将触发超时重传机制，重传未响应的报文。...如果宕机恢复了，就会回一个rst报文，重置这个tcp连接；如果没恢复，重传没有响应，就会在一定的重传次数后通过socket告知应用程序该tcp故障。该时间不定，具体要查看linxu内核参数。
调用第三方接口要考虑异常和超时处理 如果你调用第三方接口，或者分布式远程服务的的话，需要考虑： 异常处理 比如，你调别人的接口，如果异常了，怎么处理，是重试还是当做失败还是告警处理。...其实就是就是你要锁住的范围是多大。比如你在家上卫生间，你只要锁住卫生间就可以了吧，不需要将整个家都锁起来不让家人进门吧，卫生间就是你的加锁粒度。 我们写代码时，如果不涉及到共享资源，就没有必要锁住的。...22.接口要考虑异常处理 实现一个好的接口，离不开优雅的异常处理。对于异常处理，提十个小建议吧： 尽量不要使用e.printStackTrace(),而是使用log打印。...有关于加签验签的，大家可以看下我这篇文章哈：程序员必备基础：加签验签 除了加签验签和token机制，接口报文一般是要加密的。当然，用https协议是会对报文加密的。...所以接口定义要清晰易懂，命名规范。 33. 接口的版本控制 接口要做好版本控制。就是说，请求基础报文，应该包含version接口版本号字段，方便未来做接口兼容。
多线程竞争时，会引起上下文切换，所以多线程处理数据时，可以用一些办法来避免使用锁，如将数据的ID按照Hash取模分段，不同的线程处理不同段的数据 CAS算法。...Java的Atomic包使用CAS算法来更新数据，而不需要加锁。 控制线程数量。避免创建不需要的线程，比如任务很少，但是创建了很多线程来处理，这样会造成大量线程都处于等待状态 协程。...SYN-SENT：表示客户端已发送SYN报文。当客户端SOCKET执行connect()进行连接时，它首先发送SYN报文，然后随即进入到SYN_SENT状态。...SYN_RCVD：表示服务器接收到了来自客户端请求连接的SYN报文。当TCP连接处于此状态时，再收到客户端的ACK报文，它就会进入到ESTABLISHED状态。...接下来呢，你需要检查自己是否还有数据要发送给对方，如果没有的话，那你也就可以`close()`这个SOCKET并发送FIN报文给对方，即关闭自己到对方这个方向的连接 FIN-WAIT-2：主动关闭端接到
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
