问题背景 公司有一套消息推送系统(简称GCM),由于人事变动接手了其中的客户端部分.看了一下文档,仅通讯协议部分有几页简单的说明,代码呢又多又乱,一时理不出一个头绪.由于消息是从后台推送到端的,所以使用了 tcp 长连接通道来保证消息的及时性,基于 http 的一堆分析工具(如 postman)完全没有用武之地,因此决定写个小工具来模拟 tcp 上的通讯协议,作为深入熟悉代码之前的热身. 问题的解决 一开始想用 c++ 来写这个工具,但是想到 socket 一连串经典的(socket / bin…

最近工作中需要做TCP层面的负载均衡,以前网站用的反向代理nginx只支持应用层的负载均衡,对于TCP协议是无能为力的,需要使用LVS(linux虚拟服务器). LVS的特点是高性能和极复杂的配置.对网络环境的要求比较高.最近苦于LVS的配置测试,网上的文档和社区都比较少,按照各种教程配置,TCP报文均无法连通,再往下深究就要去研究公司虚机的网络结构了... 在寻找LVS配置调试方法时,看到一篇最近的文章讲4月28日刚刚发布的nginx1.90,添加了支持TCP协议的负载均衡的,如果只是需要做T…

最近有在做tcp协议性能测试,总结一下遇到的坑吧. 首先呢,我这边用的是16进制的报文: (1)TCPClient classname:org.apache.jmeter.protocol.tcp.sampler.BinaryTCPClientImpl TCPClient classname 该参数一般有三个值设置: org.apache.jmeter.protocol.tcp.sampler.TCPClientImpl(以文本编辑器中的纯文本作为内容发送) org.apache.jmeter.…

TCP协议以可靠性出名,这其中包括三次握手建立连接,流控制和拥塞控制等技术.详细介绍如下: 1. TCP协议将需要发送的数据分割成数据块.数据块大小是通过MSS(maximum segment size)来控制的,这种机制是一种协商机制,MSS规定了传往接收方的最大数据块的大小.MSS通过SYN报文协商的,若接收方不接受来自另一方的MSS值,则MSS就定为一个固定值.MSS值越大,网络的利用率越高. 2. 重传.设置定时器,等待确认包. 3. 对首部和数据进行校验. 4. TCP对收到的数据进行…

linux系统的安装: 1.linux系统的安装方式三种: 1.独立安装linux系统. 2.虚拟机安装linux系统. a.安装虚拟机,基本是一路点下去. b.安装linux. c.linux 安装的时候,分区是关键. /boot 分区 100M. /swap 交换分区.一般是物理内存的2倍,不超过256M. /root 根分区.尽可能的大. 3.双系统安装. 2 linux下的shell 3.TCP/IP 协议 4.samba服务器.主要是linux和window的交互.…

一.基于tcp协议的套接字(通信循环+链接循环) 服务端应该遵循: 1.绑定一个固定的ip和port 2.一直对外提供服务,稳定运行 3.能够支持并发 基础版套接字: from socket import * server = socket(AF_INET, SOCK_STREAM) server.bind(('127.0.0.1', 8080)) server.listen(5) conn, client_addr = server.accept() # 通信循环 while True: da…

什么是 Socket Socket 是应用层与 TCP/IP 协议通信的中间软件抽象层,它是一组接口.在设计模式中,Socket 其实就是一个门面模式,它把复杂的 TCP/IP 协议族隐藏在 Socket 接口后面,对用户来说,一组简单的接口就是全部,让 Socket 去组织数据,以符合指定的协议. 所以,我们无需深入理解 TCP/UDP 协议,socket 已经为我们封装好了,我们只需要遵循 socket 的规定去编程,写出的程序自然就是遵循 TCP/UDP 标准的. 套接字的分类: 基于文件…

TCP协议粘包问题详解 前言 在本章节中,我们将探讨TCP协议基于流式传输的最大一个问题,即粘包问题.本章主要介绍TCP粘包的原理与其三种解决粘包的方案.并且还会介绍为什么UDP协议不会产生粘包. 基于TCP协议的socket实现远程命令输入 我们准备做一个可以在Client端远程执行Server端shell命令并拿到其执行结果的程序,而涉及到网络通信就必然会出现socket模块,关于如何抉择传输层协议的选择?我们选择使用TCP协议,因为它是可靠传输协议且数据量支持比UDP协议要大.好了废话不多…

毕业后稀里糊涂的闭门造车了两年,自己的独立博客也写了两年,各种乱七八糟,最近准备把自己博客废了,现在来看了下这两年写的对我来说略微有点意义的文章只此一篇,转载过来以作留念. 写的很肤浅且凌乱,请见谅. 我的服务器主要完成一个内网音视频实时转发功能,以及其他一些业务.设计大概如下: 服务器上分为接收线程,业务处理线程,发送线程.接收线程socket绑定到完成端口.业务处理线程是采用多线程的模拟完成端口,发送线程也是多线程采用模拟完成端口.这样做的目的是想业务处理线程阻塞并不影响发送和接收. 客户端…

为了解决这题,可以具体看看下面这个讨论. 解灵运工程师 185 人赞同 某次架构师大会上那个58同城做即时通信的人说:原因是因为当时没有epoll这种可以支持成千上万tcp并发连接的技术,所以他们使用了udp,然后在udp上面封装了一下,模拟了一下tcp,解决了大并发的问题,之后因为做的很nb了,虽然epoll这种技术出现了,还是没有改回使用tcp了.现在再做类似的东西就不需要使用udp了.这个说法应该比较可信的. 发布于 2014-04-16 18 条评论 感谢 分享 收藏 • 没有帮助 • …