tcp数据偏移怎么算(tcp首部数据偏移)

如图，TCP头共20字节，而选项如果有的话，则为4字节。头和选项的原型定义如下： /*TCP头定义，共20个字节*/typedef struct _TCP_HEADER { short m_sSourPort;　　　　　　// 源端口号16bit short m_sDestPort; 　　　　　　 // 目的端口号16bit unsigned int m_uiSequNum; 　　// 序列号32bit unsigned int m_uiAcknowledgeNum;// 确认号32bit short m_sHeaderLenAndFlag;　　// 前4位：TCP头长度；中6位：保留；后6位：标志位 short m_sWindowSize; 　　　　　// 窗口大小16bit short m_sCheckSum;　　　　　 // 检验和16bit short m_surgentPointer;　　　　 // 紧急数据偏移量16bit}__attribute__((packed))TCP_HEADER, *PTCP_HEADER; /*TCP头中的选项定义 kind(8bit)+Length(8bit，整个选项的长度，包含前两部分)+内容(如果有的话) KIND = 1表示 无操作NOP，无后面的部分 2表示 maximum segment 后面的LENGTH就是maximum segment选项的长度（以byte为单位，1+1+内容部分长度） 3表示 windows scale 后面的LENGTH就是 windows scale选项的长度（以byte为单位，1+1+内容部分长度） 4表示 SACK permittedLENGTH为2，没有内容部分 5表示这是一个SACK包 LENGTH为2，没有内容部分 8表示时间戳，LENGTH为10，含8个字节的时间戳*/ typedef struct _TCP_OPTIONS{ char m_ckind; char m_cLength; char m_cCo担肌曹可丨玖查雪肠磨ntext[32];}__attribute__((packed))TCP_OPTIONS, *PTCP_OPTIONS;

TCP校验和是一个端到端的校验和，由发送端计算，然后由接收端验证。其目的是为了发现TCP首部和数据在发送端到接收端之间发生的任何改动。如果接收方检测到校验和有差错，则TCP段会被直接丢弃。TCP校验和覆盖TCP首部和TCP数据，而IP首部中的校验和只覆盖IP的首部，不覆盖IP数据报中的任何数据。TCP的校验和是必需的，而UDP的校验和是可选的。TCP和UDP计算校验和时，都要加上一个12字节的伪首部。伪首部共有12字节，包含如下信息：源IP地址、目的IP地址、保留字节(置0)、传输层协议号(TCP是6)、TCP报文长度(报头+数据)。伪首部是为了增加TCP校验和的检错能力：如检查TCP报文是否收错了(目的IP地址)、传输层协议是否选对了(传输层协议号)等。首先，把伪首部、TCP报头、TCP数据分为16位的字，如果总长度为奇数个字节，则在最后增添一个位都为0的字节。把TCP报头中的校验和字段置为0（否则就陷入鸡生蛋还是蛋生鸡的问题）。其次，用反码相加法累加所有的16位字（进位也要累加）。最后，对计算结果取反，作为TCP的校验和。实现基于2.6.18、x86_64。csum_tcpudp_nofold()按4字节累加伪首部到sum中。[java] view plaincopystatic inline unsigned long csum_tcpudp_nofold (unsigned long saddr, unsigned long daddr,unsigned short len, unsigned short proto,unsigned int sum){asm("addl %1, %0n"    /* 累加daddr */"adcl %2, %0n"    /* 累加saddr */"adcl %3, %0n"    /* 累加len(2字节), proto, 0*/"adcl $0, %0n"    /*加上进位 */: "=r" (sum): "g" (daddr), "g" (saddr), "g" ((ntohs(len) << 16) + proto*256), "0" (sum));return sum;}csum_tcpudp_magic()产生最终的校验和。首先，按4字节累加伪首部到sum中。其次，累加sum的低16位、sum的高16位，并且对累加的结果取反。最后，截取sum的高16位，作为校验和。[java] view plaincopystatic inline unsigned short int csum_tcpudp_magic(unsigned long saddr, unsigned long daddr,unsigned short len, unsigned short proto,unsigned int sum){return csum_fold(csum_tcpudp_nofold(saddr, daddr, len, proto, sum));}static inline unsigned int csum_fold(unsigned int sum){__asm__("addl %1, %0n""adcl 0xffff, %0": "=r" (sum): "r" (sum << 16), "0" (sum & 0xffff0000)/* 将sum的低16位，作为寄存器1的高16位，寄存器1的低16位补0。* 将sum的高16位，作为寄存器0的高16位，寄存器0的低16位补0。* 这样，addl %1, %0就累加了sum的高16位和低16位。** 还要考虑进位。如果有进位，adcl 0xfff, %0为：0x1 + 0xffff + %0，寄存器0的高16位加1。* 如果没有进位，adcl 0xffff, %0为：0xffff + %0，对寄存器0的高16位无影响。*/);return (~sum) >> 16; /* 对sum取反，返回它的高16位，作为最终的校验和 */}发送校验[java] view plaincopy#define CHECKSUM_NONE 0 /* 需要由传输层自己计算校验和 */#define CHECKSUM_HW 1 /* 由硬件计算报头和首部的校验和 */#define CHECKSUM_UNNECESSARY 2 /* 表示不需要校验，或者已经成功校验了 */#define CHECKSUM_PARTIAL CHECKSUM_HW#define CHECKSUM_COMPLETE CHECKSUM_HW@tcp_transmit_skb()icsk->icsk_af_ops->send_check(sk, skb->len, skb); /* 计算校验和 */[java] view plaincopyvoid tcp_v4_send_check(struct sock *sk, int len, struct sk_buff *skb){struct inet_sock *inet = inet_sk(sk);struct tcphdr *th = skb->h.th;if (skb->ip_summed == CHECKSUM_HW) {/* 只计算伪首部，TCP报头和TCP数据的累加由硬件完成 */th->check = ~tcp_v4_check(th, len, inet->saddr, inet->daddr, 0);skb->csum = offsetof(struct tcphdr, check); /* 校验和值在TCP首部的偏移 */} else {/* tcp_v4_check累加伪首部，获取最终的校验和。* csum_partial累加TCP报头。* 那么skb->csum应该是TCP数据部分的累加，这是在从用户空间复制时顺便累加的。*/th->check = tcp_v4_check(th, len, inet->saddr, inet->daddr,csum_partial((char *)th, th->doff << 2, skb->csum));}}[java] view plaincopyunsigned csum_partial(const unsigned char *buff, unsigned len, unsigned sum){return add32_with_carry(do_csum(buff, len), sum);}static inline unsigned add32_with_carry(unsigned a, unsigned b){asm("addl %2, %0nt""adcl $0, %0": "=r" (a): "0" (a), "r" (b));return a;}do_csum()用于计算一段内存的校验和，这里用于累加TCP报头。具体计算时用到一些技巧：1. 反码累加时，按16位、32位、64位来累加的效果是一样的。2. 使用内存对齐，减少内存操作的次数。[java] view plaincopystatic __force_inline unsigned do_csum(const unsigned char *buff, unsigned len){unsigned odd, count;unsigned long result = 0;if (unlikely(len == 0))return result;/* 使起始地址为XXX0，接下来可按2字节对齐 */odd = 1 & (unsigned long) buff;if (unlikely(odd)) {result = *buff << 8; /* 因为机器是小端的 */len--;buff++;}count = len >> 1; /* nr of 16-bit words，这里可能余下1字节未算，最后会处理*/if (count) {/* 使起始地址为XX00，接下来可按4字节对齐 */if (2 & (unsigned long) buff) {result += *(unsigned short *)buff;count--;len -= 2;buff += 2;}count >>= 1; /* nr of 32-bit words，这里可能余下2字节未算，最后会处理 */if (count) {unsigned long zero;unsigned count64;/* 使起始地址为X000，接下来可按8字节对齐 */if (4 & (unsigned long)buff) {result += *(unsigned int *)buff;count--;len -= 4;buff += 4;}count >>= 1; /* nr of 64-bit words，这里可能余下4字节未算，最后会处理*//* main loop using 64byte blocks */zero = 0;count64 = count >> 3; /* 64字节的块数，这里可能余下56字节未算，最后会处理 */while (count64) { /* 反码累加所有的64字节块 */asm ("addq 0*8(%[src]), %[res]nt"    /* b、w、l、q分别对应8、16、32、64位操作 */"addq 1*8(%[src]), %[res]nt"    /* [src]为指定寄存器的别名，效果应该等同于0、1等 */"adcq 2*8(%[src]), %[res]nt""adcq 3*8(%[src]), %[res]nt""adcq 4*8(%[src]), %[res]nt""adcq 5*8(%[src]), %[res]nt""adcq 6*8(%[src]), %[res]nt""adcq 7*8(%[src]), %[res]nt""adcq %[zero], %[res]": [res] "=r" (result): [src] "r" (buff), [zero] "r" (zero), "[res]" (result));buff += 64;count64--;}/* 从这里开始，反序处理之前可能漏算的字节 *//* last upto 7 8byte blocks，前面按8个8字节做计算单位，所以最多可能剩下7个8字节 */count %= 8;while (count) {asm ("addq %1, %0nt""adcq %2, %0n": "=r" (result): "m" (*(unsigned long *)buff), "r" (zero), "0" (result));--count;buff += 8;}/* 带进位累加result的高32位和低32位 */result = add32_with_carry(result>>32, result&0xffffffff);/* 之前始按8字节对齐，可能有4字节剩下 */if (len & 4) {result += *(unsigned int *) buff;buff += 4;}}/* 更早前按4字节对齐，可能有2字节剩下 */if (len & 2) {result += *(unsigned short *) buff;buff += 2;}}/* 最早之前按2字节对齐，可能有1字节剩下 */if (len & 1)result += *buff;/* 再次带进位累加result的高32位和低32位 */result = add32_with_carry(result>>32, result & 0xffffffff);/* 这里涉及到一个技巧，用于处理初始地址为奇数的情况 */if (unlikely(odd)) {result = from32to16(result); /* 累加到result的低16位 *//* result为：0 0 a b* 然后交换a和b，result变为：0 0 b a*/result = ((result >> 8) & 0xff) | ((result & oxff) << 8);}return result; /* 返回result的低32位 */}[java] view plaincopystatic inline unsigned short from32to16(unsigned a){unsigned short b = a >> 16;asm ("addw %w2, %w0nt""adcw $0, %w0n": "=r" (b): "0" (b), "r" (a));return b;}csum_partial_copy_from_user()用于拷贝用户空间数据到内核空间，同时计算用户数据的校验和，结果保存到skb->csum中（X86_64）。[java] view plaincopy/*** csum_partial_copy_from_user - Copy and checksum from user space.* @src: source address (user space)* @dst: destination address* @len: number of bytes to be copied.* @isum: initial sum that is added into the result (32bit unfolded)* @errp: set to -EFAULT for an bad source address.** Returns an 32bit unfolded checksum of the buffer.* src and dst are best aligned to 64bits.*/unsigned int csum_partial_copy_from_user(const unsigned char __user *src,unsigned char *dst, int len, unsigned int isum, int *errp){might_sleep();*errp = 0;if (likely(access_ok(VERIFY_READ, src, len))) {/* Why 6, not 7? To handle odd addresses aligned we would need to do considerable* complications to fix the checksum which is defined as an 16bit accumulator. The fix* alignment code is primarily for performance compatibility with 32bit and that will handle* odd addresses slowly too.* 处理X010、X100、X110的起始地址。不处理X001，因为这会使复杂度大增加。*/if (unlikely((unsigned long)src & 6)) {while (((unsigned long)src & 6) && len >= 2) {__u16 val16;*errp = __get_user(val16, (__u16 __user *)src);if (*errp)return isum;*(__u16 *)dst = val16;isum = add32_with_carry(isum, val16);src += 2;dst += 2;len -= 2;}}/* 计算函数是用纯汇编实现的，应该是因为效率吧 */isum = csum_parial_copy_generic((__force void *)src, dst, len, isum, errp, NULL);if (likely(*errp == 0))return isum; /* 成功 */}*errp = -EFAULT;memset(dst, 0, len);return isum;}上述的实现比较复杂，来看下最简单的csum_partial_copy_from_user()实现（um）。[java] view plaincopyunsigned int csum_partial_copy_from_user(const unsigned char *src,unsigned char *dst, int len, int sum,int *err_ptr){if (copy_from_user(dst, src, len)) { /* 拷贝用户空间数据到内核空间 */*err_ptr = -EFAULT; /* bad address */return (-1);}return csum_partial(dst, len, sum); /* 计算用户数据的校验和，会存到skb->csum中 */}

在网络分析领域，偏移量是一个频繁出现的术语，如IP分段偏移量、TCP偏移量、位偏移，基于数据包偏移、基于协议偏移等等。那它们到底是什么含义，有什么区别呢？带着这些疑问，我查阅了一些TCP/IP书籍，并对其有了一定的了解。下面我就将我的个人理解与大家一起共同分享。欢迎拍砖啊！　：） 1　IP分段偏移量IP数据包在网络中进行传输，如果数据包的大小超过网络设备的MTU值，则需要进行分段传输。分段偏移量用来标识数据包在该数据流中的位置，也可以理解为使用同一个IP标识发送多个数据包时的顺序号。发送主机给第一个分段数据包的偏移量赋值为0，对于其后的分段，该偏移量的值是MTU值减去上一个IP报头的大小，所以我们也可以说IP分段偏移量是指数据包中某个分段相对与第一分段在数据包中的位置。下面我们举一个实例。我在我的机器（192.168.0.90）的CMD窗口中执行“ping 192.168.0.1 -l 3000 -n 1”命令，同时在科来网络分析系统中设定一个过滤器，只捕获从192.168.0.90到192.168.0.1的单方向数据，由于3000远远大于了以太网的MTU值，所以它会被分段传输。这时我们来看捕获到的数据包，如图1所示。（图1IP分段偏移量）从图1可知中，共捕获到了三个数据包，第一个协议是ICMP，后面两个是IP Fragment，前面两个数据包的大小是1518字节，第三个是86字节。第一个数据包的IP偏移量是0，第二个是185，第三个是370。这三个数据包的详细情况如下表：数据包编号IP分段标志IP偏移量传输数据1更多分段置10　　0字节1518-14-20-8-4＝14722更多分段置1185　1480字节1518-14-20-4＝14803更多分段置0370　2960字节　86-14-20-4＝48上表中，第1个数据包中，多了一个ICMP报头，所以在计算传输的数据时，多减了8个字节的ICMP报头，而后面的两个数据包由于存在ICMP的报头开销，所以不需要减去8字节的ICMP报头。将传输的数据加起来，1472+1480+48=3000，与测试的数据完全吻合。注意：如果有更多的分段，按照此规则依次累加即可，同时所有分段数据包的IP标识都是相同的。2　TCP偏移量TCP偏移量出现在TCP报头里，它主要是指TCP报头的长度。TCP偏移量字段的长度是1字节，以32比特（4个字节）字长表示TCP报头的长度。不包含选项的TCP报头长为20个字节，用TCP偏移量来表示就是5（5X4=20个字节），如图2所示。如果TCP报头中有选项，TCP的报头长度则会按照4的倍数进行累加，如有一个选项时，TCP报头长度是24字节，这时TCP偏移量是6，有两个选项时，TCP报头长度是28字节，这时TCP偏移量是7。（图2无选项情况下的TCP偏移量）3　位偏移量有些报头的某些字段，每位都表示不同的含义，而一个数据包可同时有1位或多位置1，比如TCP标志字段。简单的说位偏移量是指字段中某一位在该字段中的位置。我们来看看TCP的标志字段。如图3所示。（图3TCP标志字段）图3中高亮显示的是同步位置1时的情况，也就是说该数据包是一个TCP同步数据包。TCP同步数据包的值是TCP标志位的值是10（二进制）或02（16进制）或2（10进制，8进制）。同时我们从图中可知，该字段中的每一位都有不同的掩码，我们在特定分析需要设定位偏移的过滤器时，即可通过设定该掩码的值实现过滤。如只希望捕获网络中的同步数据包，我们只需设定如图4所示的过滤器并根据该过滤器捕获数据即可。4　基于数据包偏移和基于协议偏移偏移量的计算一般按两种类型：基于数据包类型和基于协议偏移。4.1　基于数据包偏移基于数据包偏移的偏移量算法，是从以太网报头作为基准点，向后开始计算特定字段的偏移量，这里我仍然以TCP标志字段为例，说明基于数据包偏移的偏移量计算方法。图5所示的是一个TCP确认数据包，我们借助图5查看TCP标志位的偏移量。（图5按数据包类型）由于是以以太网报头作基准，所以这个数据包中的TCP标志位偏移量应该是以下报头的相加的总和：Ethernet II报头14，IP报头20，TCP源端口2，TCP目标端口2，TCP序列号4，TCP确认号4，TCP偏移量1。所以，在基于数据包偏移的情况下，该数据包的TCP标志字段偏移量是14+20+2+2+4+4+1=47。4.2　基于协议偏移基于协议偏移的偏移量算法，是以某种协议为基准点，向后开始计算特定字段的偏移量，而并非从以太网报头开始。我们还是以图5中TCP标志位偏移量来举例。在这种情况下，这个数据包如果按照TCP协议进行偏移，那么TCP标志位的偏移量应该是以下字段的相加总和：TCP源端口2，TCP目标端口2，TCP序列号4，TCP确认号4，TCP偏移量1。所以，TCP标志字段在这个数据包的偏移量是2+2+4+4+1=13。注意： 基于数据包的偏移，只匹配了偏移值，没有进行协议匹配，可能出现误差。所以，在精确度较高，且分析软件支持的情况下，应尽量使用基于协议偏移的偏移量计算方法，这样的分析结果可能更准确。
谈到硬盘逻辑锁加锁原理，就不得不提到硬盘分区表的结构。硬盘分区表位于硬盘的 0 磁道 0 柱面第1扇区（即0区）（注意：该扇区为隐含扇区，0道0面的全部扇区均为隐含扇区，普通的磁盘访问命令无法直接访问，同时该磁道的其他62个扇区也是隐含的，因此有引多系统引导程序就把自己的程序代码放在其他隐含扇区，有些引导区病毒也把自己的代码放在其他隐含扇区。）。在该扇区512字节中，硬盘的主引导记录区MBR （Main Boot Record）只占用了前 446 个字节（偏移 000H-- 偏移 1BDH ），另外的 64个字节（偏移 1BEH-- 偏移 1FDH ）是硬盘分区表DPT(Disk Partition Table ) , 最后两个字节 "55 AA" （偏移 1FEH－偏移 1FFH ）是分区结束标志。

TCP协议是在TCP/IP协议模型中的运输层中很重要的一个协议、负责处理主机端口层面之间的数据传输。主要有以下特点：1.TCP是面向链接的协议，在数据传输之前需要通过三次握手建立TCP链接，当数据传递完成之后，需要通过四次挥手进行连接释放。2.每一条TCP通信都是两台主机和主机之间的，是点对点传输的协议。3.TCP提供可靠的、无差错、不丢失、不重复，按序到达的服务。4.TCP的通信双方在连接建立的任何时候都可以发送数据。TCP连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据。5.面向字节流。在数据传输的过程中如果报文比较长的话TCP会进行数据分段传输，每一条分段的TCP传输信息都带有分段的序号，每一段都包含一部分字节流。接收方根据每段携带的的序号信息进行数据拼接，最终拼接出来初始的传输数据。但是在整个传输的过程中每一段TCP携带的都是被切割的字节流数据。所以说TCP是面向字节流的。a.TCP和UDP在发送报文时所采用的方式完全不同。TCP并不关心应用程序一次把多长的报文发送到TCP缓存中，而是根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节（UDP发送的报文长度是应用程序给出的）。b.如果应用程序传送到TCP缓存的数据块太大，TCP就可以把它划分短一些再传。TCP也可以等待积累有足够多的字节后再构建成报文段发送出去。各字段含义：源端口：发送端的端口号目的端口：接收端的端口号序号：TCP将发送报文分段传输的时候会给每一段加上序号，接收端也可以根据这个序号来判断数据拼接的顺序，主要用来解决网络报乱序的问题确认号：确认号为接收端收到数据之后进行排序确认以及发送下一次期待接收到的序号，数值 = 接收到的发送号 + 1数据偏移：占4比特，表示数据开始的地方离TCP段的起始处有多远。实际上就是TCP段首部的长度。由于首部长度不固定，因此数据偏移字段是必要的。数据偏移以32位为长度单位，因此TCP首部的最大长度是60（15*4）个字节。控制位：URG：此标志表示TCP包的紧急指针域有效，用来保证TCP连接不被中断，并且督促 中间层设备要尽快处理这些数据;ACK：此标志表示应答域有效，就是说前面所说的TCP应答号将会包含在TCP数据包中;有两个取值：0和1， 为1的时候表示应答域有效，反之为0;PSH：这个标志位表示Push操作。所谓Push操作就是指在数据包到达接收端以后，立即传送给应用程序， 而不是在缓冲区中排队;RST：这个标志表示连接复位请求。用来复位那些产生错误的连接，也被用来拒绝错误和非法的数据包;SYN：表示同步序号，用来建立连接。SYN标志位和ACK标志位搭配使用，当连接请求的时候，SYN=1， ACK=0;连接被响应的时候，SYN=1，ACK=1;这个标志的数据包经常被用来进行端口扫描。扫描者发送 一个只有SYN的数据包，如果对方主机响应了一个数据包回来 ，就表明这台主机存在这个端口;但是由于这 种扫描方式只是进行TCP三次握手的第一次握手，因此这种扫描的成功表示被扫描的机器不很安全，一台安全 的主机将会强制要求一个连接严格的进行TCP的三次握手;FIN： 表示发送端已经达到数据末尾，也就是说双方的数据传送完成，没有数据可以传送了，发送FIN标志 位的TCP数据包后，连接将被断开。这个标志的数据包也经常被用于进行端口扫描。窗口：TCP里很重要的一个机制，占2字节，表示报文段发送方期望接收的字节数，可接收的序号范围是从接收方的确认号开始到确认号加上窗口大小之间的数据。后面会有实例讲解。校验和：校验和包含了伪首部、TCP首部和数据，校验和是TCP强制要求的，由发送方计算，接收方验证紧急指针：URG标志为1时，紧急指针有效，表示数据需要优先处理。紧急指针指出在TCP段中的紧急数据的最后一个字节的序号，使接收方可以知道紧急数据共有多长。选项：最常用的选项是最大段大小（Maximum Segment Size，MSS），向对方通知本机可以接收的最大TCP段长度。MSS选项只在建立连接的请求中发送。放在以太网帧里看TCP的位置TCP 数据包在 IP 数据包的负载里面。它的头信息最少也需要20字节，因此 TCP 数据包的最大负载是 1480 - 20 = 1460 字节。由于 IP 和 TCP 协议往往有额外的头信息，所以 TCP 负载实际为1400字节左右。因此，一条1500字节的信息需要两个 TCP 数据包。HTTP/2 协议的一大改进， 就是压缩 HTTP 协议的头信息，使得一个 HTTP 请求可以放在一个 TCP 数据包里面，而不是分成多个，这样就提高了速度。以太网数据包的负载是1500字节，TCP 数据包的负载在1400字节左右一个包1400字节，那么一次性发送大量数据，就必须分成多个包。比如，一个 10MB 的文件，需要发送7100多个包。发送的时候，TCP 协议为每个包编号（sequence number，简称 SEQ），以便接收的一方按照顺序还原。万一发生丢包，也可以知道丢失的是哪一个包。第一个包的编号是一个随机数。为了便于理解，这里就把它称为1号包。假定这个包的负载长度是100字节，那么可以推算出下一个包的编号应该是101。这就是说，每个数据包都可以得到两个编号：自身的编号，以及下一个包的编号。接收方由此知道，应该按照什么顺序将它们还原成原始文件。收到 TCP 数据包以后，组装还原是操作系统完成的。应用程序不会直接处理 TCP 数据包。对于应用程序来说，不用关心数据通信的细节。除非线路异常，否则收到的总是完整的数据。应用程序需要的数据放在 TCP 数据包里面，有自己的格式（比如 HTTP 协议）。TCP 并没有提供任何机制，表示原始文件的大小，这由应用层的协议来规定。比如，HTTP 协议就有一个头信息Content-Length，表示信息体的大小。对于操作系统来说，就是持续地接收 TCP 数据包，将它们按照顺序组装好，一个包都不少。操作系统不会去处理 TCP 数据包里面的数据。一旦组装好 TCP 数据包，就把它们转交给应用程序。TCP 数据包里面有一个端口（port）参数，就是用来指定转交给监听该端口的应用程序。应用程序收到组装好的原始数据，以浏览器为例，就会根据 HTTP 协议的Content-Length字段正确读出一段段的数据。这也意味着，一次 TCP 通信可以包括多个 HTTP 通信。服务器发送数据包，当然越快越好，最好一次性全发出去。但是，发得太快，就有可能丢包。带宽小、路由器过热、缓存溢出等许多因素都会导致丢包。线路不好的话，发得越快，丢得越多。最理想的状态是，在线路允许的情况下，达到最高速率。但是我们怎么知道，对方线路的理想速率是多少呢？答案就是慢慢试。TCP 协议为了做到效率与可靠性的统一，设计了一个慢启动（slow start）机制。开始的时候，发送得较慢，然后根据丢包的情况，调整速率：如果不丢包，就加快发送速度；如果丢包，就降低发送速度。Linux 内核里面 设定 了（常量TCP_INIT_CWND），刚开始通信的时候，发送方一次性发送10个数据包，即"发送窗口"的大小为10。然后停下来，等待接收方的确认，再继续发送。默认情况下，接收方每收到 两个TCP 数据包，就要 发送 一个确认消息。"确认"的英语是 acknowledgement，所以这个确认消息就简称 ACK。ACK 携带两个信息。发送方有了这两个信息，再加上自己已经发出的数据包的最新编号，就会推测出接收方大概的接收速度，从而降低或增加发送速率。这被称为"发送窗口"，这个窗口的大小是可变的。注意，由于 TCP 通信是双向的，所以双方都需要发送 ACK。两方的窗口大小，很可能是不一样的。而且 ACK 只是很简单的几个字段，通常与数据合并在一个数据包里面发送。即使对于带宽很大、线路很好的连接，TCP 也总是从10个数据包开始慢慢试，过了一段时间以后，才达到最高的传输速率。这就是 TCP 的慢启动。TCP 协议可以保证数据通信的完整性，这是怎么做到的？前面说过，每一个数据包都带有下一个数据包的编号。如果下一个数据包没有收到，那么 ACK 的编号就不会发生变化。举例来说，现在收到了4号包，但是没有收到5号包。ACK 就会记录，期待收到5号包。过了一段时间，5号包收到了，那么下一轮 ACK 会更新编号。如果5号包还是没收到，但是收到了6号包或7号包，那么 ACK 里面的编号不会变化，总是显示5号包。这会导致大量重复内容的 ACK。如果发送方发现收到 三个 连续的重复 ACK，或者超时了还没有收到任何 ACK，就会确认丢包，即5号包遗失了，从而再次发送这个包。通过这种机制，TCP 保证了不会有数据包丢失。TCP是一个滑动窗口协议，即一个TCP连接的发送端在某个时刻能发多少数据是由滑动窗口控制的，而滑动窗口的大小实际上是由两个窗口共同决定的，一个是接收端的通告窗口，这个窗口值在TCP协议头部信息中有，会随着数据的ACK包发送给发送端，这个值表示的是在接收端的TCP协议缓存中还有多少剩余空间，发送端必须保证发送的数据不超过这个剩余空间以免造成缓冲区溢出，这个窗口是接收端用来进行流量限制的，在传输过程中，通告窗口大小与接收端的进程取出数据的快慢有关。另一个窗口是发送端的拥塞窗口(Congestion window)，由发送端维护这个值，在协议头部信息中没有，滑动窗口的大小就是通告窗口和拥塞窗口的较小值，所以拥塞窗口也看做是发送端用来进行流量控制的窗口。滑动窗口的左边沿向右移动称为窗口合拢，发生在发送的数据被确认时（此时，表明数据已被接收端收到，不会再被需要重传，可以从发送端的发送缓存中清除了），滑动窗口的右边沿向右移动称为窗口张开，发生在接收进程从接收端协议缓存中取出数据时。随着发送端不断收到的被发送数据的ACK包，根据ACK包中的确认序号和通告窗口大小使滑动窗口得以不断的合拢和张开，形成滑动窗口的向前滑动。如果接收进程一直不取数据，则会出现0窗口现象，即滑动窗口左边沿与右边沿重合，此时窗口大小为0，就无法再发送数据。在TCP里，接收端(B)会给发送端(A)报一个窗口的大小，叫Advertised window。1.在没有收到B的确认情况下，A可以连续把窗口内的数据都发送出去。凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。2.发送窗口里面的序号表示允许发送的序号。显然，窗口越大，发送方就可以在收到对方确认之前连续发送更多数据，因而可能获得更高的传输效率。但接收方必须来得及处理这些收到的数据。3.发送窗口后沿的后面部分表示已发送且已收到确认。这些数据显然不需要再保留了。4.发送窗口前沿的前面部分表示不允许发送的，应为接收方都没有为这部分数据保留临时存放的缓存空间。5.发送窗口后沿的变化情况有两种：不动（没有收到新的确认）和前移（收到了新的确认）6.发送窗口前沿的变化情况有两种：不断向前移或可能不动（没收到新的确认）TCP的发送方在规定时间内没有收到确认就要重传已发送的报文段。这种重传的概念很简单，但重传时间的选择确是TCP最复杂的问题之一。TCP采用了一种自适应算法，它记录一个报文段发出的时间，以及收到响应的确认的时间这两个时间之差就是报文段的往返时间RTT。TCP保留了RTT的一个加权平均往返时间。超时重传时间RTO略大于加权平均往返时间RTT：即Round Trip Time，表示从发送端到接收端的一去一回需要的时间，tcp在数据传输过程中会对RTT进行采样（即对发送的数据包及其ACK的时间差进行测量，并根据测量值更新RTT值，具体的算法TCPIP详解里面有），TCP根据得到的RTT值更新RTO值，即Retransmission TimeOut，就是重传间隔，发送端对每个发出的数据包进行计时，如果在RTO时间内没有收到所发出的数据包的对应ACK，则任务数据包丢失，将重传数据。一般RTO值都比采样得到的RTT值要大。如果收到的报文段无差错，只是未按序号，中间还缺少一些序号的数据，那么能否设法只传送缺少的数据而不重传已经正确到达接收方的数据？答案是可以的，选择确认就是一种可行的处理方法。如果要使用选项确认SACK，那么在建立TCP连接时，就要在TCP首部的选项中加上“允许SACK”的选项，而双方必须都事先商定好。如果使用选择确认，那么原来首部中的“确认号字段”的用法仍然不变。SACK文档并没有明确发送方应当怎么响应SACK.因此大多数的实现还是重传所有未被确认的数据块。一般说来，我们总是希望数据传输的更快一些，但如果发送方把数据发送的过快，接收方就可能来不及接收，这会造成数据的丢失。所谓流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。在计算机网络中的链路容量，交换节点中的缓存和处理机等，都是网络的资源。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫做拥塞。拥塞控制方法：1.慢开始和拥塞避免2.快重传和快恢复3.随机早期检测1.一开始，客户端和服务端都处于CLOSED状态2.先是服务端主动监听某个端口，处于LISTEN状态（比如服务端启动，开始监听）。3.客户端主动发起连接SYN，之后处于SYN-SENT状态（第一次握手，发送 SYN = 1 ACK = 0 seq = x ack = 0）。4.服务端收到发起的连接，返回SYN，并且ACK客户端的SYN，之后处于SYN-RCVD状态（第二次握手，发送 SYN = 1 ACK = 1 seq = y ack = x + 1）。5.客户端收到服务端发送的SYN和ACK之后，发送ACK的ACK，之后处于ESTABLISHED状态（第三次握手，发送 SYN = 0 ACK = 1 seq = x + 1 ack = y + 1）。6.服务端收到客户端的ACK之后，处于ESTABLISHED状态。（需要注意的是，有可能X和Y是相等的，可能都是0，因为他们代表了各自发送报文段的序号。）TCP连接释放四次挥手1.当前A和B都处于ESTAB-LISHED状态。2.A的应用进程先向其TCP发出连接释放报文段，并停止再发送数据，主动关闭TCP连接。3.B收到连接释放报文段后即发出确认，然后B进入CLOSE-WAIT(关闭等待)状态。TCP服务器进程这时应通知高层应用进程，因而从A到B这个方向的连接就释放了，这时TCP连接处于半关闭状态，即A已经没有数据发送了。从B到A这个方向的连接并未关闭，这个状态可能会持续一些时间。4.A收到来自B的确认后，就进入FIN-WAIT-2(终止等待2)状态，等待B发出的连接释放报文端。5.若B已经没有向A发送的数据，B发出连接释放信号，这时B进入LAST-ACK(最后确认)状态等待A的确认。6.A再收到B的连接释放消息后，必须对此发出确认，然后进入TIME-WAIT（时间等待）状态。请注意，现在TCP连接还没有释放掉，必须经过时间等待计时器（TIME－WAIT timer）设置的时间2MSL后，A才进入CLOSED状态。7。B收到A发出的确认消息后，进入CLOSED状态。以请求百度为例，看一下三次握手真实数据的TCP连接建立过程我们再来看四次挥手。TCP断开连接时，会有四次挥手过程，标志位是FIN，我们在封包列表中找到对应位置，理论上应该找到4个数据包，但我试了好几次，实际只抓到3个数据包。查了相关资料，说是因为服务器端在给客户端传回的过程中，将两个连续发送的包进行了合并。因此下面会按照合并后的三次挥手解释，若有错误之处请指出。第一步，当主机A的应用程序通知TCP数据已经发送完毕时，TCP向主机B发送一个带有FIN附加标记的报文段（FIN表示英文finish）。第二步，主机B收到这个FIN报文段之后，并不立即用FIN报文段回复主机A，而是先向主机A发送一个确认序号ACK，同时通知自己相应的应用程序：对方要求关闭连接（先发送ACK的目的是为了防止在这段时间内，对方重传FIN报文段）。第三步，主机B的应用程序告诉TCP：我要彻底的关闭连接，TCP向主机A送一个FIN报文段。第四步，主机A收到这个FIN报文段后，向主机B发送一个ACK表示连接彻底释放。这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。原因有二：一、保证TCP协议的全双工连接能够可靠关闭二、保证这次连接的重复数据段从网络中消失先说第一点，如果Client直接CLOSED了，那么由于IP协议的不可靠性或者是其它网络原因，导致Server没有收到Client最后回复的ACK。那么Server就会在超时之后继续发送FIN，此时由于Client已经CLOSED了，就找不到与重发的FIN对应的连接，最后Server就会收到RST而不是ACK，Server就会以为是连接错误把问题报告给高层。这样的情况虽然不会造成数据丢失，但是却导致TCP协议不符合可靠连接的要求。所以，Client不是直接进入CLOSED，而是要保持TIME_WAIT，当再次收到FIN的时候，能够保证对方收到ACK，最后正确的关闭连接。再说第二点，如果Client直接CLOSED，然后又再向Server发起一个新连接，我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题，但是还是有特殊情况出现：假设新连接和已经关闭的老连接端口号是一样的，如果前一次连接的某些数据仍然滞留在网络中，这些延迟数据在建立新连接之后才到达Server，由于新连接和老连接的端口号是一样的，又因为TCP协议判断不同连接的依据是socket pair，于是，TCP协议就认为那个延迟的数据是属于新连接的，这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME_WAIT状态等待2倍MSL，这样可以保证本次连接的所有数据都从网络中消失。硬件速度网络和服务器的负载请求和响应报文的尺寸客户端和服务器之间的距离TCP 协议的技术复杂性TCP 连接建立握手；TCP 慢启动拥塞控制；数据聚集的 Nagle 算法；用于捎带确认的 TCP 延迟确认算法；TIME_WAIT 时延和端口耗尽。介绍完毕，就这？是的，就这。补充：大部分内容为网络整理，方便自己学习回顾，参考文章：TCP 协议简介TCP协议图文详解什么是TCP协议？wireshark抓包分析——TCP/IP协议TCP协议的三次握手和四次挥手TCP协议详解TCP带宽和时延的研究(1)

要了解三次握手&四次挥手的过程，就需要对TCP的报头以及有限状态机的概念有所了解，本文将介绍TCP报头的字段的含义，以及有限状态机各个状态的意义，最后对三次握手和四次挥手的过程做介绍 TCP（Transmission Control Protocol 传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793定义。在简化的计算机网络OSI模型中，它完成第四层传输层所指定的功能，用户数据报协议（UDP）是同一层内另一个重要的传输协议。在因特网协议族（Internet protocol suite）中，TCP层是位于IP层之上，应用层之下的中间层。不同主机的应用层之间经常需要可靠的、像管道一样的连接，但是IP层不提供这样的流机制，而是提供不可靠的包交换。这里将介绍TCP报头的特性以及TCP报头各个字段的含义.工作在传输层面向连接协议.全双工协议.半关闭.错误检查.将数据打包成段，排序.确认机制.数据恢复，重传.流量控制，滑动窗口.拥塞控制，慢启动和拥塞避免算法.源端口、目标端口 ：计算机上的进程要和其他进程通信是要通过计算机端口的，而一个计算机端口某个时刻只能被一个进程占用，所以通过指定源端口和目标端口，就可以知道是哪两个进程需要通信。源端口、目标端口是用16位表示的，可推算计算机的端口个数为2^16个. 序列号 ：表示本报文段所发送数据的第一个字节的编号。在TCP连接中所传送的字节流的每一个字节都会按顺序编号。由于序列号由32位表示，所以每2^32个字节，就会出现序列号回绕，再次从0 开始. 确认号 ：表示接收方期望收到发送方下一个报文段的第一个字节数据的编号。也就是告诉发送发：我希望你（指发送方）下次发送的数据的第一个字节数据的编号是这个确认号. 数据偏移 ：表示TCP报文段的首部长度，共4位，由于TCP首部包含一个长度可变的选项部分，需要指定这个TCP报文段到底有多长。它指出TCP 报文段的数据起始处距离TCP 报文段的起始处有多远。该字段的单位是32位(即4个字节为计算单位），4位二进制最大表示15，所以数据偏移也就是TCP首部最大60字节. URG ：表示本报文段中发送的数据是否包含紧急数据。后面的紧急指针字段（urgent pointer）只有当URG=1时才有效. ACK ：表示是否前面的确认号字段是否有效。ACK=1，表示有效。只有当ACK=1时，前面的确认号字段才有效。TCP规定，连接建立后，ACK必须为1,带ACK标志的TCP报文段称为确认报文段. PSH ：提示接收端应用程序应该立即从TCP接收缓冲区中读走数据，为接收后续数据腾出空间。如果为1，则表示对方应当立即把数据提交给上层应用，而不是缓存起来，如果应用程序不将接收到的数据读走，就会一直停留在TCP接收缓冲区中. RST ：如果收到一个RST=1的报文，说明与主机的连接出现了严重错误（如主机崩溃），必须释放连接，然后再重新建立连接。或者说明上次发送给主机的数据有问题，主机拒绝响应，带RST标志的TCP报文段称为复位报文段. SYN ：在建立连接时使用，用来同步序号。当SYN=1，ACK=0时，表示这是一个请求建立连接的报文段；当SYN=1，ACK=1时，表示对方同意建立连接。SYN=1，说明这是一个请求建立连接或同意建立连接的报文。只有在前两次握手中SYN才置为1，带SYN标志的TCP报文段称为同步报文段. FIN ：表示通知对方本端要关闭连接了，标记数据是否发送完毕。如果FIN=1，即告诉对方：“我的数据已经发送完毕，你可以释放连接了”，带FIN标志的TCP报文段称为结束报文段. 窗口大小 ：表示现在充许对方发送的数据量，也就是告诉对方，从本报文段的确认号开始允许对方发送的数据量. 校验和 ：提供额外的可靠性. 紧急指针 ：标记紧急数据在数据字段中的位置. 选项部分 ：其最大长度可根据TCP首部长度进行推算。TCP首部长度用4位表示，选项部分最长为：(2^4-1)*4-20=40字节常见选项 ：.最大报文段长度：MaxiumSegment Size，MSS.窗口扩大：Windows Scaling.时间戳：Timestamps.a 最大报文段长度指明自己期望对方发送TCP报文段时那个数据字段的长度。默认是536字节。数据字段的长度加上TCP首部的长度才等于整个TCP报文段的长度。MSS不宜设的太大也不宜设的太小。若选择太小，极端情况下，TCP报文段只含有1字节数据，在IP层传输的数据报的开销至少有40字节（包括TCP报文段的首部和IP数据报的首部）。这样，网络的利用率就不会超过1/41。若TCP报文段非常长，那么在IP层传输时就有可能要分解成多个短数据报片。在终点要把收到的各个短数据报片装配成原来的TCP报文段。当传输出错时还要进行重传，这些也都会使开销增大。因此MSS应尽可能大，只要在IP层传输时不需要再分片就行。在连接建立过程中，双方都把自己能够支持的MSS接入这一字段。MSS只出现在SYN报文中。即：MSS出现在SYN=1的报文段中.b 窗口扩大为了扩大窗口，由于TCP首部的窗口大小字段长度是16位，所以其表示的最大数是65535。但是随着时延和带宽比较大的通信产生（如卫星通信），需要更大的窗口来满足性能和吞吐率，所以产生了这个窗口扩大选项.c 时间戳可以用来计算RTT(往返时间)，发送方发送TCP报文时，把当前的时间值放入时间戳字段，接收方收到后发送确认报文时，把这个时间戳字段的值复制到确认报文中，当发送方收到确认报文后即可计算出RTT。也可以用来防止回绕序号PAWS，也可以说可以用来区分相同序列号的不同报文。因为序列号用32为表示，每2^32个序列号就会产生回绕，那么使用时间戳字段就很容易区分相同序列号的不同报文2.3 TCP协议PORT.传输层通过port号，确定应用层协议.Port number:. tcp ：0-65535,传输控制协议，面向连接的协议；通信前需要建立虚拟链路；结束后拆除链路.. udp ：0-65535,User Datagram Protocol，无连接的协议.. IANA :互联网数字分配机构（负责域名，数字资源，协议分配）0-1023：系统端口或特权端口(仅管理员可用) ，众所周知，永久的分配给固定的系统应用使用，22/tcp(ssh), 80/tcp(http), 443/tcp(https)1024-49151：用户端口或注册端口，但要求并不严格，分配给程序注册为某应用使用，1433/tcp(SqlServer)，1521/tcp(oracle),3306/tcp(mysql),11211/tcp/udp(memcached)49152-65535：动态端口或私有端口，客户端程序随机使用的端口其范围的定义：/proc/sys/net/ipv4/ip_local_port_range有限状态机，（英语：Finite-state machine, FSM），又称有限状态自动机，简称状态机，是表示有限个状态以及在这些状态之间的转移和动作等行为的数学模型。常见的计算机就是使用有限状态机作为计算模型的：对于内存的不同状态，CPU通过读取内存值进行计算，更新内存中的状态。CPU还通过消息总线接受外部输入设备（如键盘、鼠标）的指令，计算后更改内存中的状态，计算结果输出到外部显示设备（如显示器），以及持久化存储在硬盘。TCP协议也存在有限状态机的概念，TCP 协议的操作可以使用一个具有 11 种状态的有限状态机来表示.CLOSED 没有任何连接状态.LISTEN 侦听状态，等待来自远方TCP端口的连接请求.SYN-SENT 在发送连接请求后，等待对方确认.SYN-RECEIVED 在收到和发送一个连接请求后，等待对方确认.ESTABLISHED 代表传输连接建立，双方进入数据传送状态.FIN-WAIT-1 主动关闭,主机已发送关闭连接请求，等待对方确认.FIN-WAIT-2 主动关闭,主机已收到对方关闭传输连接确认，等待对方发送关闭传输连接请求.TIME-WAIT 完成双向传输连接关闭，等待所有分组消失.CLOSE-WAIT 被动关闭,收到对方发来的关闭连接请求，并已确认.LAST-ACK 被动关闭,等待最后一个关闭传输连接确认，并等待所有分组消失.CLOSING 双方同时尝试关闭传输连接，等待对方确认.客户端通过connect系统调用主动与服务器建立连接connect系统调用首先给服务器发送一个同步报文段，使连接转移到SYN_SENT状态。.此后connect系统调用可能因为如下两个原因失败返回：.1、如果connect连接的目标端口不存在（未被任何进程监听），或者该端口仍被处于TIME_WAIT状态的连接所占用（见后文），则服务器将给客户端发送一个复位报文段，connect调用失败。.2、如果目标端口存在，但connect在超时时间内未收到服务器的确认报文段，则connect调用失败。.connect调用失败将使连接立即返回到初始的CLOSED状态。如果客户端成功收到服务器的同步报文段和确认，则connect调用成功返回，连接转移至ESTABLISHED状态.当客户端执行主动关闭时，它将向服务器发送一个结束报文段FIN，同时连接进入FIN_WAIT_1状态。若此时客户端收到服务器专门用于确认目的的确认报文段，则连接转移至FIN_WAIT_2状态。当客户端处于FIN_WAIT_2状态时，服务器处于CLOSE_WAIT状态，这一对状态是可能发生半关闭的状态。此时如果服务器也关闭连接（发送结束报文段），则客户端将给予确认并进入TIME_WAIT状态.客户端从FIN_WAIT_1状态可能直接进入TIME_WAIT状态（不经过FIN_WAIT_2状态），前提是处于FIN_WAIT_1状态的服务器直接收到带确认信息的结束报文段（而不是先收到确认报文段，再收到结束报文段）注意，客户端先发送一个FIN给服务端，自己进入了FIN_WAIT_1状态，这时等待接收服务端的报文，该报文会有三种可能：a 只有服务端的ACK，只收到服务器的ACK，客户端会进入FIN_WAIT_2状态，后续当收到服务端的FIN时，回应发送一个ACK，会进入到TIME_WAIT状态，这个状态会持续2MSL(TCP报文段在网络中的最大生存时间,RFC 1122标准的建议值是2min).客户端等待2MSL，是为了当最后一个ACK丢失时，可以再发送一次。因为服务端在等待超时后会再发送一个FIN给客户端，进而客户端知道ACK已丢失b 只有服务端的FIN，回应一个ACK给服务端，进入CLOSING状态，然后接收到服务端的ACK时，进入TIME_WAIT状态c 同时收到服务端的ACK和FIN，直接进入TIME_WAIT状态.收到服务器ACK后，客户端处于FIN_WAIT_2状态，此时需要等待服务器发送结束报文段，才能转移至TIME_WAIT状态，否则它将一直停留在这个状态。如果不是为了在半关闭状态下继续接收数据，连接长时间地停留在FIN_WAIT_2状态并无益处。连接停留在FIN_WAIT_2状态的情况可能发生在：客户端执行半关闭后，未等服务器关闭连接就强行退出了。此时客户端连接由内核来接管，可称之为孤儿连接（和孤儿进程类似）。.Linux为了防止孤儿连接长时间存留在内核中，定义了两个内核参数：./proc/sys/net/ipv4/tcp_max_orphans 指定内核能接管的孤儿连接数目./proc/sys/net/ipv4/tcp_fin_timeout指定孤儿连接在内核中生存的时间TCP协议中的三次握手和四次挥手客户机端的三次握手和四次挥手服务器端的三次握手和四次挥手1 client 首先发送一个连接试探，此时ACK=0,表示确认号无效，SYN=1表示这是一个请求连接或连接接受报文，同时表示这个数据包不携带数据，seq=x表示此时client自己数据的初始序号是x,这时候client进入syn_sent状态，表示客户端等等服务器的回复2 server 监听到连接请求报文后，如同意建立连接，则向client发送确认，将TCP报文首部的SYN和ACK都置为1，因为client上一个请求连接的报文中seq=x,所以服务器端这次就发ack=x+1,表示服务器端希望客户端下一个报文段的第一个数据字节序号是x+1，同时表示x为止的所有数据都已经正确收到了，其中，此时服务器端发送seq=y表示server自己的初始序号是y，这时服务器进入了SYN_RCVD状态，表示服务器已经收到了客户端的请求，等待client的确认。3 client收到确认后还要再次给服务器端发送确认，同时携带要发给server的数据。ACK=1表示确认号ack=y+1有效，client这时的序号seq为x+1一旦client确认后，这个TCP连接的client 和 server 都直接进入到established状态，可以发起http请求了4.2 四次挥手详解第一次挥手：client向server，发送FIN报文段，表示关闭数据传送，此时ACK=0,seq=u,表示客户端此时数据的报文序号是u，此时，client进入FIN_WAIT_1状态，表示没有数据要传输了第二次挥手：server收到FIN报文段后进入CLOSE_WAIT状态（被动关闭），然后发送ACK确认，表示同意你关闭请求了，主机到主机的数据链路关闭，同时发送seq=v,表示此时server端的数据包字节序号是v,ack=u+1,表示希望client发送的下一个包的序号是u+1,表示确认了序号u之前的包都已经收到，客户端收到server的ACK报文后，进入FIN_WAIT_2状态第三次挥手：server等待client发送完数据，发送FIN=1，ACK=1到client请求关闭，server进入LAST_ACK状态。此时发送的seq有变化，因为上一个ACK的后server端可能又发送了一些数据，说以数据字节序号发送了变化，为w,但是ack还是保持不变第四次挥手：client收到server发送的FIN后，回复ACK确认到server，client进入TIME_WAIT状态。发送ack=w+1,表示希望服务器下个发送的报文的字节序号是w+1,确认了服务器之前发送的w字节都已经正确收到，发送seq=u+1表示当前client的字节序号是u+1.server收到client的ACK后就关闭连接了，状态为CLOSED。client等待2MSL，仍然没有收到server的回复，说明server已经正常关闭了，client关闭连接。其中，MSL（Maximum Segment Lifetime）：报文最大生存时间，是任何报文段被丢弃前在网络内的最长时间。当client回复server的FIN后，等待(2-4分钟)，即使两端的应用程序结束。TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态的原因是如果client直接进入CLOSED状态，由于IP协议不可靠性或网络问题，导致client最后发出的ACK报文未被server接收到，那么server在超时后继续向client重新发送FIN，而client已经关闭，那么找不到向client发送FIN的连接，server这时收到RST并把错误报告给高层，不符合TCP协议的可靠性特点。如果client直接进入CLOSED状态，而server还有数据滞留在网络中，当有一个新连接的端口和原来server的相同，那么当原来滞留的数据到达后，client认为这些数据是新连接的。等待2MSL确保本次连接所有数据消失。 当客户端等待2MSL后服务器端没有再次发送确认的报文后，client认为该次断开连接已经正常结束，client进入closed状态。四次挥手正式结束