互联网把无数的手机、电脑、服务器、路由器、交换机等各种设备连接在一块儿，那这些设备之间要通过网络通信，自然就需要一套通信协议，TCP/IP就是这样一套协议。
版权声明：本文为木偶人shaon原创文章，转载请注明原文地址，非常感谢。 https://blog.csdn.net/wh211212/article/details/53389557
ping 是常用的网络管理命令，ping也属于一个通信协议，是TCP/IP协议的一部分，适用于windows和linux以及unix。根据reply 反馈结果，来检查网络是否通畅或者网络连接的速度（time）是否正常。主要是端对端的，针对目标ip或者目标网址。
看到了一道面试题：“为什么TCP建立连接协议是三次握手，而关闭连接却是四次握手呢？为什么不能用两次握手进行连接？”，想想最近也到金三银四了，所以就查阅了相关资料，整理出来了这篇文章，希望对你们有所帮助。
机器一般过质保之后，就会因为各种各样的问题而宕机。而这一次的宕机，让笔者观察到了平常观察不到的tcp在对端宕机情况下的行为。经过详细跟踪分析原因之后，发现可以通过调整内核tcp参数来减少宕机造成的影响。
刚才下班回家路上，无意中听到大街上放的歌，歌词有这么一句：“毡房外又有驼铃声声响起，我知道那一定不是你”。这一句我似乎听懂了歌者的魂牵梦绕和绝望，如果在十年前我大概只能感受出悠扬的声调里溢出的悲凉吧。
首先通过我们内部搭建的日志平台发现我们线上环境一个java应用有大量的http接口请求超时，登录linux服务器查看网络环境没有问题，判断是应用自身运行异常，重启应用后发现异常还在，开始查找问题。
接入层nginx集群某个接口偶尔出现502，但是业务nginx没有看到502日志，业务服务端口正常。
最近，业务增长的很迅猛，对于我们后台这块也是一个不小的挑战，这次遇到的核心业务接口的性能瓶颈，并不是单独的一个问题导致的，而是几个问题揉在一起：我们解决一个之后，发上线，之后发现还有另一个的性能瓶颈问题。这也是我经验不足，导致没能一下子定位解决；而我又对我们后台整个团队有着固执的自尊，不想通过大量水平扩容这种方式挺过压力高峰，导致线上连续几晚都出现了不同程度的问题，肯定对于我们的业务增长是有影响的。这也是我不成熟和要反思的地方。这系列文章主要记录下我们针对这次业务增长，对于我们后台微服务系统做的通用技术优化，针对业务流程和缓存的优化由于只适用于我们的业务，这里就不再赘述了。本系列会分为如下几篇：
浏览器debug 调试一打开 Nginx 就 504 Gateway Time-out
本篇博文分享一款开源的Modbus协议栈。 协议栈支持Modbus主机和从机两种模式，并且支持两种模式同时开启。从机支持Modbus RTU 、Modbus ASCII及Modbus TCP 3种模式，主机现在只支持常用的Modbus RTU模式。 资源下载：https://download.csdn.net/download/m0_38106923/87997766
当tcp进行三次握手的时候 , 第一步是客户端发送syn请求 , 服务端返回syn+sck , 客户端响应sck
在上篇教程中，我们介绍了 Go 语言中可以通过 Dial() 函数建立网络连接。实际上，Dial() 函数是对 dialTCP()、dialUDP()、dialIP() 和 dialUnix() 的封装，这可以通过追溯 Dial() 函数的源码看到，底层真正建立连接是通过 dialSingle() 函数完成的：
wrk 是一个能够在单个多核 CPU 上产生显著负载的现代 HTTP 基准测试工具。它采用了多线程设计，并使用了像 epoll 和 kqueue 这样的可扩展事件通知机制。此外，用户可以指定 LuaJIT 脚本来完成 HTTP 请求生成、响应处理和自定义报告等功能。
windows中的tracert使用的icmp，linux中使用的traceroute是udp报文和icmp返回（？？）
先说明一下环境，这里有四台主机，中间的Centos充当防火墙。右上角的win XP和右下角的Rhel7充当服务器，最左边的win7充当主机。四者之间的网卡都已经配置好。而且我们已经在Centos6.5上开启了端口转发功能。
应用执行SQL请求完成的过程中，数据库连接占很重要一部分。尤其是涉及到流量瞬间暴涨，需要创建大量连接，或者网络异常导致重连时，从业务端来看，sql执行缓慢的问题，此时sql执行并非真的慢。本文是基于我们自己的生产环境的Durid最佳实践，仅供各位参考，当然不同公司的链路/业务压力可能不一样。具体到个别参数需要区别对待。
一、超时 可以告诉 requests 在经过以 timeout 参数设定的秒数时间之后停止等待响应。 连接超时指的是在你的客户端实现到远端机器端口的连接时Request 会等待的秒数。一个很好的实践方法是把连接超时设为比 3 的倍数略大的一个数值，因为 TCP 数据包重传窗口 (TCP packet retransmission window) 的默认大小是 3
集群内节点负载过高，频繁脱离集群，引起健康状态变化，节点分片未分配，影响集群业务。
如上图所示，关键部分：syns queue（半连接队列）和accept queue（全连接队列）
之前说了 CPU、内存 、IO 在排查过程中可能出现的问题以及出现问题会影响的指标，这次就来看看在 linux 中网络的问题。
其实对这种和数据库交互的应用，现在的程序中，大多都用了数据库连接池，无论用的开源，还是自研的，无非都是想通过连接池，更方便、更高效地和数据库交互，因此一定程度上，连接池的正确使用会关系到应用和数据库交互的质量。一 前言
在爬虫代理这一块我们经常会遇到请求超时的问题，代码就卡在哪里，不报错也没有requests请求的响应。
Whistle 是一个基于 Node.js 的跨平台抓包调试代理工具。它不仅支持 HTTP 和 HTTPS 请求的截获和修改，还支持 WebSocket、TCP 等多种协议。通过简单的配置，开发者可以轻松实现流量监控、数据篡改、请求转发、Mock 数据等功能。
在多线程环境下使用HttpClient组件对某个HTTP服务发起请求，运行一段时间之后发现客户端主机CPU利用率呈现出下降趋势，而不是一个稳定的状态。 而且，从程序日志中判断有线程处于hang住的状态，应该是被阻塞了。
https://www.cnblogs.com/davis12/p/14548367.html
通常来说，一个优化良好的 Nginx Linux 服务器可以达到 500,000 – 600,000 次/秒 的请求处理性能，然而我的 Nginx 服务器可以稳定地达到 904,000 次/秒 的处理性能，并且我以此高负载测试超过 12 小时，服务器工作稳定。
本文告诉大家如何在 dotnet 6 下使用 HttpClient 更加精细的控制网络请求的超时，实现 HttpWebRequest 的 ReadWriteTimeout 功能
Asyhchronous 异步 javascript And XML $.ajax({ type: 'GET', // 这是请求的方式 可以是GET方式也可以是POST方式, 默认是GET url: ' xxx.php ', // 这是请求的连接地址 一般情况下这个地址是后台给前端的一个连接，直接写就可以 dataType: 'json', // 这是后台返回的数据类型 一般情况下都是一个json数据， 前端遍历一下就OK
通过设置 Transport 结构中的 Dial 的属性来实现。如上面的代码中，Dial 的 Timetout 是在 tcp 连接时设置的连接超时，Deadline 则会在超过这个时间后强制关闭连接，在连接无响应的时候回有用。KeepAlive 则会发起心跳，检测连接是否存活。此外，可以设置 TLSHandshakeTimeout 作为 https 握手的超时。具体可以参考 net.Dialer 的文档。由于直接构造了 Transport 结构，不会自动设置 Proxy 属性，这里还得再这里补上。可以用 http.ProxyFromEnvironment 表示根据环境变量来设置，即 http_proxy 和 https_proxy 两个变量设置的 http 代理。如果想强制不使用代理，可以设置为
安装代理接口 1.检查操作系统版本和内核版本 lsb_release 操作系统 ********************************** LSB Version: :core-3.1-amd64:core-3.1-ia32:core-3.1-noarch:graphics-3.1-amd64:graphics-3.1-ia32:graphics-3.1-noarch Distributor ID: RedHatEnterpriseServer Description: Red Hat Enterprise Linux Server release 5.4 (Tikanga) Release: 5.4 Codename: Tikanga ********************************** uname -r 内核版本 ********************************** 2.6.18-164.el5 ********************************** 2.安装代理接口 在线代理下载HAproxy 1.5.9版本 安装步骤 （1）tar xzvf haproxy-1.5.9.tar.gz ********************************** haproxy-1.5.9/ haproxy-1.5.9/.gitignore haproxy-1.5.9/CHANGELOG haproxy-1.5.9/LICENSE haproxy-1.5.9/Makefile haproxy-1.5.9/README haproxy-1.5.9/ROADMAP haproxy-1.5.9/SUBVERS haproxy-1.5.9/VERDATE haproxy-1.5.9/VERSION haproxy-1.5.9/contrib/ ...... haproxy-1.5.9/tests/test_hashes.c haproxy-1.5.9/tests/test_pools.c haproxy-1.5.9/tests/testinet.c haproxy-1.5.9/tests/uri_hash.c ***************************************************** (2)针对内核版本进行安装 安装前先要看看内核的版本，我这里是2.6.18 make TARGET=linux26 PREFIX=/usr/local/hapropxy make install PREFIX=/usr/local/haproxy (3)设置配置文件 cd /usr/local/haproxy vi haproxy.cfg ***************************************************** ###########全局配置######### global log 127.0.0.1 local0 #[日志输出配置，所有日志都记录在本机，通过local0输出] log 127.0.0.1 local1 notice #定义haproxy 日志级别[error warringinfo debug] daemon #以后台形式运行harpoxy #nbproc 1 #设置进程数量 pidfile /usr/local/haproxy/haproxy.pid #haproxy 进程PID文件 #ulimit-n 819200 #ulimit 的数量限制 maxconn 4096 #默认最大连接数,需考虑ulimit-n限制 chroot /usr/local/haproxy #chroot运行路径 uid 99 #运行haproxy 用户 UID gid 99 #运行haproxy 用户组gid #debug #haproxy 调试级别，建议只在开启单进程的时候调试 #quiet ########默认配置############ defaults log global mode http #默认的模式mode { tcp|http|health }，tcp是4层，http是7层，health只会返回OK #option httplog #日
相信很多小伙伴都碰到过一个问题，服务运行过程中，产生大量的未关闭的TCP链接，导至服务不可用直至服务异常。 该如何定位、排查这些未关闭的链接? 之前碰到过这个问题，解决了，今天有小伙伴又聊到这个问题，
通常来说，一个优化良好的 Linux 服务器可以达到 500,000 – 600,000 次/秒 的请求处理性能，然而我的 Nginx 服务器可以稳定地达到 904,000 次/秒 的处理性能，并且我以此高负载测试超过 12 小时，服务器工作稳定。 这里需要特别说明的是，本文中所有列出来的配置都是在我的测试环境验证的，而你需要根据你服务器的情况进行配置： 从 EPEL 源安装 Nginx： yum -y install nginx 备份配置文件，然后根据你的需要进行配置： cp /etc/nginx/ngi
工作中经常要用到nginx，这里将使用nginx最常要用到的技巧记录下来以备忘。 安装 在linux或mac下安装nginx还是很简单的，我一般都是直接下载源代码编译安装。这里要注意，configure时它会提示缺少某些开发库，按照它说明的安装上就可以编译了。另外我一般是将nginx的源码目录留下来，以免以后在用的过程中缺少某个module，需要重新编译安装。 mkdir build/ tar xf nginx-x.y.z.tar.gz -C build/ cd build/nginx-x.y.z ./co
httpbin 服务作为接收请求的服务端， sleep 服务作为发送请求的客户端。
upstream_check_module模块可以用来检测后端服务的健康状态，如果后端服务器不可用，则所有的请求不转发到这台服务器 upstream_check_module模块是第三方模块，并不是Nginx提供的 模块地址 https://github.com/yaoweibin/nginx_upstream_check_module
我们知道TCP建立连接的时候需要三次连接，TCP释放连接的时候需要四次挥手，在这个过程中，出现了很多特殊的标志报文段，例如SYN ACK FIN，在TCP协议中，除了上面说了那些标志报文段之外，还有其他的报文段，如PUSH标志报文段以及今天需要重点讲解的RST报文段。
对于云上的用户来说，业务日志里面报超时问题处理起来往往比价棘手，因为1) 问题点可能在云基础设施层，也有可能在业务软件层，需要排查的范围非常广；2) 这类问题往往是不可复现问题，抓到现场比较难。在本文里就分析下如何来分辨和排查这类问题的根本原因。
1、新建文件夹rediscluster。 mkdir -p /usr/local/redis/rediscluster/7001 mkdir -p /usr/local/redis/rediscluster/7002 2、拷贝单机搭建好的Redis文件夹到7001、7002目录下。 单机部署参考《Redis安装在Linux系统》 cp /usr/local/redis/* /usr/loca/redis/rediscluster/7001/ cp /usr/local/redis/* /usr/loca/r
大家好，我叫杜杨浩，很高兴今天在这里给大家分享一下Kubernetes集群高可用&备份还原方案。无论是高可用还是备份还原都是生产环境所必须具备的特性，本次分享将依次介绍我在实现这些特性过程中遇到的问题，以及相应的思考和解决方案。
分区方式一般有三种 第一种：数据不是很重要 /boot（系统的引导分区）： 系统引导的信息/软件 系统的内核 200M swap（ 交换分区）： 为了避免系统内存用光了导致系统 宕机 如果系统内存不够了，系统会临时使用swap(交换分区) 大小：如果你的内存小于8G 则swap 给内存的1.5倍 以后使用的时候给512M 如果你的内存大于8G 则swap 给8G即可。 / （根分区）： 剩余多少给多少 第二种：数据很重要 /boot（系统的引导分区）： 系统引导的信息/软件 系统的内核 200
关注腾讯云大学，了解行业最新技术动态 腾讯云大学知识分享月已经开幕了 为了让大家沉淀知识， 我们邀请了 杜杨浩讲师 将直播内容整理成了文章 话不多说让我们再来回顾一下课程内容吧 （课程精彩片段，戳阅读原文观看完整回放） 直 播 回 顾 前言 大家好，我叫杜杨浩，很高兴今天在这里给大家分享一下Kubernetes集群高可用&备份还原方案。无论是高可用还是备份还原都是生产环境所必须具备的特性，本次分享将依次介绍我在实现这些特性过程中遇到的问题，以及相应的思考和解决方案。 Kubernetes高
在RPC的相关问题学习时提到了Socket(套接字)，用于描述ip和端口，ip指向某个服务器，端口用于连接到某个应用程序，RPC是建立在Socket的基础上，在网络通讯的过程中，对于这个过程是如何来进行的这部分知识点非常模糊，本小节来对Socket来学习一下
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
云直播
