第一个需要讨论的大概就是粘包问题了.因为这个是TCP的个性问题,UDP通信时不存在这个问题的.首先看一下什么叫粘包: 客户端采取与服务器的长连接方式建立通信(Open-Write/Read-Write/Read-……-Write/Read-Close).即建立连接之后进行多次读写操作,最后才关闭.而且不是文件传输,而是数据结构的传输(文件传输发生粘包与没发生粘包都不会影响结果,反正都是字节流的按顺序写入本地文件).举个例子来说明一下吧: 两种数据结构:{give me something} {d

Author:阿冬哥 Created:2013-4-17 Blog:http://blog.csdn.net/c359719435/ Copyright 2013 阿冬哥 http://blog.csdn.net/c359719435/ 使用以及转载请注明出处   1 设置socket tcp缓冲区大小的疑惑        疑惑1:通过setsockopt设置SO_SNDBUF.SO_RCVBUF这连个默认缓冲区的值,再用getsockopt获取设置的值,发现返回值是设置值的两倍.为什么?  

Author:阿冬哥 Created:2013-4-17 Blog:http://blog.csdn.net/c359719435/ Copyright 2013 阿冬哥 http://blog.csdn.net/c359719435/ 使用以及转载请注明出处   1 设置socket tcp缓冲区大小的疑惑        疑惑1:通过setsockopt设置SO_SNDBUF.SO_RCVBUF这连个默认缓冲区的值,再用getsockopt获取设置的值,发现返回值是设置值的两倍.为什么?  

链接来自:http://blog.csdn.net/ysu108/article/details/7764461 这个问题在前面有的部分已经涉及,这里在重新总结下.主要参考UNIX网络编程. (1)数据报大小 IPv4的数据报最大大小是65535字节,包括IPv4首部.因为首部中说明大小的字段为16位. IPv6的数据报最大大小是65575字节,包括40字节的IPv6首部.同样是展16位,但是IPv6首部大小不算在里面,所以总大小比IPv4大一个首部(40字节). (2)MTU 许多网络有一个可

这个问题在前面有的部分已经涉及,这里在重新总结下.主要参考UNIX网络编程. (1)数据报大小IPv4的数据报最大大小是65535字节,包括IPv4首部.因为首部中说明大小的字段为16位.IPv6的数据报最大大小是65575字节,包括40字节的IPv6首部.同样是展16位,但是IPv6首部大小不算在里面,所以总大小比IPv4大一个首部(40字节). (2)MTU许多网络有一个可由硬件规定的MTU.以太网的MTU为1500字节.有一些链路的MTU的MTU可以由认为配置.IPv4要求的最小链路MTU

磨刀不误砍柴工,让我们从概念入手,逐步深入. 所谓socket通常也称作"套接字",用于描述IP地址和端口,是一个通信链的句柄.应用程序通常通过"套接字"向网络发出请求或者应答网络请求.Socket通讯是我们开发多人在线游戏中的常用通讯方式,它主要有流式Socket(SOCK_STREAM)和数据报式Socket(SOCK_DGRAM)两种类别,AS3中我们一般使用的是基于TCP的流式socket,因此本文也主要讲解这一种方式.既然这篇文章主要讲解的是流式socke

//该段博文为引用,非原创. 封包和拆包 作者:fengge8ylf  博客:http://blog.csdn.net/fengge8ylf 对于基于TCP开发的通讯程序,有个很重要的问题需要解决,就是封包和拆包.自从我从事网络通讯编程工作以来(大概有三年的时间了),我一直在思索和改进封包和拆包的方法.下面就针对这个问题谈谈我的想法,抛砖引玉.若有不对,不妥之处,恳求大家指正.在此先谢过大家了. 一.为什么基于TCP的通讯程序需要进行封包和拆包. TCP是个"流"协议,所谓流,就是没有

无论是服务端还是客户端,当我们读取或者发送消息的时候,都需要考虑TCP底层的粘包/拆包机制. TCP粘包/拆包 TCP是个"流"协议,所谓流,就是没有界限的一串数据.大家可以想想河里的流水,是连成一片的,其间并没有分界线.TCP底层并不了解上层业务数据的具体含义,它会根据TCP缓冲区的实际情况进行包的划分,所以在业务上认为,一个完整的包可能会被TCP拆分成多个包进行发送,也有可能把多个小的包封装成一个大的数据包发送,这就是所谓的TCP粘包和拆包问题. TCP粘包/拆包问题说明 假设客户

章节回顾: <TCP/IP详解卷1:协议>第1章 概述-读书笔记 <TCP/IP详解卷1:协议>第2章 链路层-读书笔记 <TCP/IP详解卷1:协议>第3章 IP:网际协议(1)-读书笔记 <TCP/IP详解卷1:协议>第3章 IP:网际协议(2)-读书笔记 <TCP/IP详解卷1:协议>第4章 ARP:地址解析协议-读书笔记 <TCP/IP详解卷1:协议>第5章 RARP:逆地址解析协议-读书笔记 <TCP/IP详解卷1:协

TCP的那些事儿(下) 这篇文章是下篇,所以如果你对TCP不熟悉的话,还请你先看看上篇<TCP的那些事儿(上)> 上篇中,我们介绍了TCP的协议头.状态机.数据重传中的东西.但是TCP要解决一个很大的事,那就是要在一个网络根据不同的情况来动态调整自己的发包的速度,小则让自己的连接更稳定,大则让整个网络更稳定.在你阅读下篇之前,你需要做好准备,本篇文章有好些算法和策略,可能会引发你的各种思考,让你的大脑分配很多内存和计算资源,所以,不适合在厕所中阅读. TCP的RTT算法 从前面的TCP重传机制

原文: http://bhsc881114.github.io/2015/06/23/HTTP%E8%AF%B7%E6%B1%82%E7%9A%84TCP%E7%93%B6%E9%A2%88%E5%88%86%E6%9E%90/ 针对三次握手.流量控制(接收窗口).慢启动(cwnd,拥塞窗口).队首阻塞等方面看下TCP对HTTP的影响 这篇文章基本是对<Web性能权威指南>第一章和第二章的读书笔记,另外加一些扩展内容,这本书确实赞,推荐 高带宽和低延迟 所有网络通信都有决定性影响的两个方面:延

原文: http://coolshell.cn/articles/11609.html 这篇文章是下篇,所以如果你对TCP不熟悉的话,还请你先看看上篇<TCP的那些事儿(上)> 上篇中,我们介绍了TCP的协议头.状态机.数据重传中的东西.但是TCP要解决一个很大的事,那就是要在一个网络根据不同的情况来动态调整自己的发包的速度,小则让自己的连接更稳定,大则让整个网络更稳定.在你阅读下篇之前,你需要做好准备,本篇文章有好些算法和策略,可能会引发你的各种思考,让你的大脑分配很多内存和计算资源,所以,

简介    TCP 是一个’流’协议,所谓流,就是没有界限的一串数据. 大家可以想想河里的流水,是连成一片的.期间并没有分界线, TCP 底层并不了解上层业务数据的具体含义 ,它会根据 TCP 缓冲区的实际情况进行包得划分,所以在业务上认为,一个完整的包可能会被 TCP 拆分成多个包进行发送 . 也有可能把多个小的包封装成一个大的数据包发送,这就是所谓的 TCP 拆包和粘包.   TCP 粘包/拆包问题说明      我们可以通过图解对 TCP 粘包和拆包进行说明.粘包问题示例图:     假设

https://community.emc.com/message/821593#821593 介绍 TCP通过滑动窗口机制检测丢包,并在丢包发生时调整数据传输速率.滑动窗口机制利用数据接收端的接收窗口来控制数据流. 接收窗口值由数据接收端指定,以字节数形式存储于TCP报文头,并告知传输设备有多少数据将会存储在TCP缓冲区.缓冲区就是数据暂时放置的地方,直至传递至应用层协议等待处理.因此,发送端每次只能发送Window Size字段指定的数据量.为了使发送端继续传送数据,接收端必须发送确认信息:

转http://coolshell.cn/articles/11609.html 滑动窗口 -- 表征发送端和接收端的接收能力 拥塞窗口-- 表征中间设备的传输能力 TCP滑动窗口 需要说明一下,如果你不了解TCP的滑动窗口这个事,你等于不了解TCP协议.我们都知道,TCP必需要解决的可靠传输以及包乱序(reordering)的问题,所以,TCP必需要知道网络实际的数据处理带宽或是数据处理速度,这样才不会引起网络拥塞,导致丢包. 所以,TCP引入了一些技术和设计来做网络流控,Sliding Wi

(上) TCP是一个巨复杂的协议,因为他要解决很多问题,而这些问题又带出了很多子问题和阴暗面.所以学习TCP本身是个比较痛苦的过程,但对于学习的过程却能让人有很多收获.关于TCP这个协议的细节,我还是推荐你去看W.Richard Stevens的<TCP/IP 详解 卷1:协议>(当然,你也可以去读一下RFC793以及后面N多的RFC).另外,本文我会使用英文术语,这样方便你通过这些英文关键词来查找相关的技术文档. 之所以想写这篇文章,目的有三个, 一个是想锻炼一下自己是否可以用简单的篇幅把这

免责声明:和往常一样,此文章的观点都属于‘No Bugs’Hare(译注:一个网站) ,也许不一定和翻译者或者Overload编辑的意见一致.同时,翻译者从Lapine翻译到英语也具有一定的难度.除此之外,翻译者与Overload对于从阅读此文章所带来的后果或不作为明确不负任何责任. 原文地址:Once Again on TCP vs UDP 讨论TCP与UDP的好与坏几乎与Linux和windows的争辩有着一样长的历史.我一直支持一个观点,也就是:UDP与TCP都有各自的适用场景(比如:[N

转载自csdn:http://blog.csdn.net/zhangxinrun/article/details/6721495 这两天看csdn有一些关于socket粘包,socket缓冲区设置的问题,发现自己不是很清楚,所以查资料了解记录一下: 一 .两个简单概念长连接与短连接:1.长连接 Client方与Server方先建立通讯连接,连接建立后不断开, 然后再进行报文发送和接收. 2.短连接 Client方与Server每进行一次报文收发交易时才进行通讯连接,交易完毕后立即断开连接.此种方

这篇文章是下篇,所以如果你对TCP不熟悉的话,还请你先看看上篇<TCP的那些事儿(上)> 上篇中,我们介绍了TCP的协议头.状态机.数据重传中的东西.但是TCP要解决一个很大的事,那就是要在一个网络根据不同的情况来动态调整自己的发包的速度,小则让自己的连接更稳定,大则让整个网络更稳定.在你阅读下篇之前,你需要做好准备,本篇文章有好些算法和策略,可能会引发你的各种思考,让你的大脑分配很多内存和计算资源,所以,不适合在厕所中阅读. TCP的RTT算法 从前面的TCP重传机制我们知道Timeout的

对于基于TCP开发的通讯程序,有个很重要的问题需要解决,就是封包和拆包. 一.为什么基于TCP的通讯程序需要进行封包和拆包. TCP是个"流"协议,所谓流,就是没有界限的一串数据. 大家可以想想河里的流水,是连成一片的,其间是没有分界线的.但一般通讯程序开发是需要定义一个个相互独立的数据包的,比如用于登陆的数据包,用于注销的数据包. 由于TCP"流"的特性以及网络状况,在进行数据传输时会出现以下几种情况: 假设我们连续调用两次 send 分别发送两段数据 data1

刚刚接触SOCKET编程,网上看了一些资料,发现做些简单的应用还是不难.但是要深入了解SOCKET编程还需要系统的看一些书.一般在进程间通信TCP是一种不错的方式. ---XXX TCP链接是面向流的链接,因此数据在应用程序看来应该是没有边界的,之前对send和recv函数中发送的大小和返回值没有理解,今天做了一个实验有了进一步的了解.socket一些常用的函数介绍可以在这里找到http://blog.csdn.net/ithzhang/article/details/8448655 之前有个疑