一.TCP头信息 简单的至少应该知道,源端口,目的端口,序号,确认号,标志位,校验和 二.TCP的建立 1.客户端将SYN标志位置1,同时生成随机的序号,确认号是0. 2.服务器接收到SYN,知道有人想和他建立连接,做出回应,将SYN和ACK标志位置1,确认号为刚刚接受客户端的序号加1,代表已经收到客户端的建立连接请求.然后自己再随即生成一个序号,用来确认从服务器到客户端的链路正常. 3.客户端接收到服务器发送的确认号,检查是不是自己刚才发送的序号加一,代表从客户端到服务器的链路正确.客户端发送

Tcp协议本身是可靠的,并不等于应用程序用tcp发送数据就一定是可靠的.不管是否阻塞,send发送的大小,并不代表对端recv到多少的数据. 在阻塞模式下, send函数的过程是将应用程序请求发送的数据拷贝到发送缓存中发送并得到确认后再返回.但由于发送缓存的存在,表现为:如果发送缓存大小比请求发送的大小要大,那么send函数立即返回,同时向网络中发送数据;否则,send向网络发送缓存中不能容纳的那部分数据,并等待对端确认后再返回(接收端只要将数据收到接收缓存中,就会确认,并不一定要等待应用程序调

版权声明:本文由谢代斌原创文章,转载请注明出处: 文章原文链接:https://www.qcloud.com/community/article/108 来源:腾云阁 https://www.qcloud.com/community 研究测试TCP断开和异常的各种情况,以便于分析网络应用(比如tconnd)断网的原因和场景,帮组分析和定位连接异常掉线的问题,并提供给TCP相关的开发测试人员作为参考. 各个游戏接入都存在一定的掉线问题,而且有的游戏项目的掉线比例还比较高,现在互娱自研游戏的网络接入

Tcp协议本身是可靠的,并不等于应用程序用tcp发送数据就一定是可靠的.不管是否阻塞,send发送的大小,并不代表对端recv到多少的数据. 在阻塞模式下, send函数的过程是将应用程序请求发送的数据拷贝到发送缓存中发送并得到确认后再返回.但由于发送缓存的存在,表现为:如果发送缓存大小比请求发送的大小要大,那么send函数立即返回,同时向网络中发送数据;否则,send向网络发送缓存中不能容纳的那部分数据,并等待对端确认后再返回(接收端只要将数据收到接收缓存中,就会确认,并不一定要等待应用程序调

由于涉及面太广,只作简单整理,有兴趣的可参考<UNIX Networking Programming>volum 1, Section 5.7, 5.12, 5.14, 5.15, 6.6 以及7.5 SO_LINGER选项. 以一个简单的echo服务器为例,客户端从标准输入读入字符,发送给服务器,服务器收到后再原样返回,客户端收到后打印到标准输出. 那么,关于套接字的关闭有以下几种情形: 1,客户端关闭连接: 1.1,客户端调用close() 1.2,客户端进程关闭 1.3,客户端调用shu

前言 tcp的关闭不是简单粗暴的,相对而言是友好优雅的,好聚好散吧. 那么友好的关闭方式是这样的: 假设这里是客户端请求关闭的,服务端倒过来. 客户端:我要请求关闭 服务端:我接收到你的请求了,等我把要发的数据发完. 服务端:我要发的数据发完了,可以关闭了. 客户端:好的,我已经执行清理工作了,关闭结束. 那么这个时候为什么服务端直接告诉客户端可以直接关闭了呢? 为什么服务器端要做一些事情呢,到底有啥用. 回到设计的角度上,理论上是越简单越好的,遇到了什么问题,才使得我们要增加一个步骤呢. 那么

做题的时候遇到一个问题,TCP关闭的时候到底是三次还是四次握手,如果是三次,少了哪部分?   按照 <计算机网络> -第五版-谢希仁       然而对于TCP关闭, 有的地方能找到    FIN-ACK-FIN-ACK   有点地方却说      (ACK, FIN) - ACK - (ACK, FIN) - ACK 还有                  FIN-ACK-FIN-ACK    根据<计算机网络> 关闭的时候是      FIN- ACK-(FIN, ACK)-A

首先我们先来回顾一下tcp关闭连接的过程: 假设A和B连接状态为EST,A需要主动关闭: A发送FIN给B,并将状态更改为FIN_WAIT1, B接收到FIN将状态更改为CLOSE_WAIT,并回复ACK和FIN A收到ACK后将状态更改为FIN_WAIT2,收到FIN后,更改状态为WAIT_TIMEOUT并给B返回ACK B收到ACK后,将关闭自己的链接CLOSE. 问题就在此时,A将处于WAIT_TIMEOUT状态长达2MSL时常(RFC793定义了MSL为2分钟,Linux设置成了30s)

Close行为: 当应用程序在调用close()函数关闭TCP连接时,Linux内核的默认行为是将套接口发送队列里的原有数据(比如之前残留的数据)以及新加入 的数据(比如函数close()产生的FIN标记,如果发送队列没有残留之前的数据,那么这个FIN标记将单独产生一个新数据包)发送出去并且销毁套接口 (并非把相关资源全部释放,比如只是把内核对象sock标记为dead状态等,这样当函数close()返回后,TCP发送队列的数据包仍然可以继续由内 核协议栈发送,但是一些相关操作就会受到影响和限制,

这里主要记录一下TCP连接在关闭的时刻,有哪些细节问题.方便在以后的程序设计中能够注意这些细节, 以避免出现这些错误.首先我们来看一下TCP的状态转换图.如<unix网络编程>卷一所示如下图: TCP 四次挥手: 挥手时的序号问题 挥手过程中状态转换问题 TIME_WAIT 产生原因 挥手序号问题: 这里可以看出FIN也占用了一个序号,例如FIN M, 对方回应ACK 确认序号为M+1.最后发送FIN也是如此.那么这里的M和N在传输数据过程中怎样得到的.看一下一个抓包的例子如下 :: >

MSL(Maximum Segment Lifetime)报文最大生存时间,2MSL即两倍的MSL,TCP允许不同的实现可以设置不同的MSL值. 第一,保证客户端发送的最后一个ACK报文能够到达服务器,因为这个ACK报文可能丢失,站在服务器的角度看来,我已经发送了FIN+ACK报文请求断开了,客户端还没有给我回应,应该是我发送的请求断开报文它没有收到,于是服务器又会重新发送一次,而客户端就能在这个2MSL时间段内收到这个重传的报文,接着给出回应报文,并且会重启2MSL计时器. 第二,防止类似与“

参照: http://course.ccniit.com/CSTD/Linux/reference/files/018.PDF http://hi.baidu.com/raycomer/item/944d23d9b502d13be3108f61 建立连接: 理解:窗口和滑动窗口TCP的流量控制 TCP使用窗口机制进行流量控制 什么是窗口? 连接建立时,各端分配一块缓冲区用来存储接收的数据,并将缓冲区的尺寸发送给另一端 接收方发送的确认信息中包含了自己剩余的缓冲区尺寸 剩余缓冲区空间的数量叫做窗口

TCP连接建立和关闭中的疑难点 作者:夏语岚    撰写日期:2011-10-29 近日在阅读<Unix网络编程>,以前在<计算机网络>课程中学到TCP,当时只是简单了解了TCP连接建立的三次握手和关闭时的四次握手.并没有对其中各个状态以及其中的疑问进行深究.以下仅仅是个人的学习笔记-- 疑问1:TCP建立连接时为什么要进行第三次握手? 疑问2:TCP关闭连接时为什么是四次握手? 疑问3:为什么主动关闭的一端会出现TIME_WAIT状态? 在解答以上疑问前,先给出TCP连接建立和关

tcp关闭连接不区分客户端和服务端,哪一端口可以主动发起关闭连接请求.所以为了描述方便,描述中的“主动方”表示主动发起关闭连接一方,“被动方”表示被动关闭连接一方. 1. tcp关闭连接状态转换 上图是tcp连接主动关闭端的状态转换图: (1)应用层调用close函数发起关闭连接请求 (2)发送FIN到对端,关闭写通道,自己进入FIN_WAIT1状态 (3)等待对端的确认ACK到来,接受到ACK后进入FIN_WAIT2状态:如果在超时时间内没有收到确认ACK直接进入CLOSED状态 (4)如果在

转自:(http://www.cnblogs.com/Jessy/p/3535612.html) 参照: http://course.ccniit.com/CSTD/Linux/reference/files/018.PDF http://hi.baidu.com/raycomer/item/944d23d9b502d13be3108f61 建立连接: 理解:窗口和滑动窗口TCP的流量控制 TCP使用窗口机制进行流量控制 什么是窗口? 连接建立时,各端分配一块缓冲区用来存储接收的数据,并将缓冲区

在前面的内容中我们介绍了TCP连接管理中最常见的三次握手方式和四次挥手的方式.但是有可能A和B两端同时执行主动打开并连接对方或者同时执行主动关闭连接(尽管发生这种情况的可能性比较低低),这个时候的流程就略有不同了.下面我们分别对同时打开(simultaneous open)连接和同时关闭(simultaneous)连接这两种情况分别进行介绍. 一.同时打开连接 同时打开连接是指通信的双方在接收到对方的SYN包之前,都进行了主动打开的操作并发出了自己的SYN包.如之前所说一个四元组标识一个TCP连

建立连接: 理解:窗口和滑动窗口TCP的流量控制 TCP使用窗口机制进行流量控制 什么是窗口? 连接建立时,各端分配一块缓冲区用来存储接收的数据,并将缓冲区的尺寸发送给另一端 接收方发送的确认信息中包含了自己剩余的缓冲区尺寸 剩余缓冲区空间的数量叫做窗口 2. TCP的流控过程(滑动窗口) TCP(Transmission Control Protocol) 传输控制协议 三次握手 TCP是主机对主机层的传输控制协议,提供可靠的连接服务,采用三次握手确认建立一个连接: 位码即tcp标志位,有6种

一.TCP报文格式 下面是TCP报文格式图: (1) 序号, Seq(Sequence number), 占32位,用来标识从TCP源端向目的端发送的字节流,发起方发送数据时对此进行标记. (2) 确认号, Ack(Acknowledge number), 占32位, 只有ACK标志位为1时,确认序号字段才有效,Ack=Seq+1. (3) 标志位  有6种标示(SYN.ACK.PSH.RST.URG.FIN): ① SYN(synchronous建立联机) ② ACK(acknowledgem

建立连接: 理解:窗口和滑动窗口TCP的流量控制TCP使用窗口机制进行流量控制什么是窗口?连接建立时,各端分配一块缓冲区用来存储接收的数据,并将缓冲区的尺寸发送给另一端 接收方发送的确认信息中包含了自己剩余的缓冲区尺寸 剩余缓冲区空间的数量叫做窗口 2. TCP的流控过程(滑动窗口) TCP(Transmission Control Protocol) 传输控制协议 三次握手 TCP是主机对主机层的传输控制协议,提供可靠的连接服务,采用三次握手确认建立一个连接: 位码即tcp标志位,有6种标示:

TCP关闭过程(四次挥手): ESTABLISHED: 当前建立连接状态 CLOSE_WAIT:Server端收到来自Client端的FIN包后,发送ACK回Client端,进入CLOSE_WAIT 状态. LAST_ACK:同时Server端向上层应用告知客户端关闭消息,发送FIN包回Client端,然后进入LAST_ACK阶段,等待客户端ACK. CLOSED:Server端收到Client端Ack后,进入CLOSED状态,连接关闭. FIN_WAIT1:Client端发送FIN包,然后进入

欢迎关注公众号:bin的技术小屋,本文图片加载不出来的话可查看公众号原文 本系列Netty源码解析文章基于 4.1.56.Final版本 写在前面..... 本文是笔者肉眼盯 Bug 系列的第三弹,前两弹分别是: 抓到Netty一个Bug,顺带来透彻地聊一下Netty是如何高效接收网络连接的 ,在这篇文章中盯出了一个在 Netty 接收网络连接时,影响吞吐量的一个 Bug. 抓到Netty一个隐藏很深的内存泄露Bug | 详解Recycler对象池的精妙设计与实现,在这篇文章中盯出了一个 Net