 上传我的文档
 下载
 收藏
该文档贡献者很忙，什么也没留下。
 下载此文档
正在努力加载中...
下载积分：30
内容提示：探索TCPIP
文档格式：PDF|
浏览次数：11|
上传日期： 10:03:15|
文档星级：
该用户还上传了这些文档
官方公共微信君，已阅读到文档的结尾了呢~~
豆丁精品文档： 历史选择题解题技巧 选择题的解题方法 是非题 是非题歌词 是非题伴奏 是非题 范玮琪 是非题mv 是非题吉他谱 是非题 简谱 是非题钢琴谱
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
选择题、是非题、复习题、求解题
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer-4.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口网络协议分析题库_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
网络协议分析题库
上传于|0|0|文档简介
&&期末复习试题
阅读已结束，如果下载本文需要使用1下载券
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，查找使用更方便
还剩7页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢posts - 55,&
comments - 46,&
trackbacks - 0
1.TCP连接的建立
& & &设主机B运行一个服务器进程，它先发出一个被动打开命令，告诉它的TCP要准备接收客户进程的连续请求，然后服务进程就处于听的状态。不断检测是否有客户进程发起连续请求，如有，作出响应。设客户进程运行在主机A中，他先向自己的TCP发出主动打开的命令，表明要向某个IP地址的某个端口建立运输连接，过程如下：
& & &1）主机A的TCP向主机B的TCP发出连接请求报文段，其首部中的同步比特SYN应置1，同时选择一个序号x，表明在后面传送数据时的第一个数据字节的序号是x。
& & &2）主机B的TCP收到连接请求报文段后，如同意，则发挥确认。在确认报文段中应将SYN置为1，确认号应为x+1，同时也为自己选择一个序号y
& & &3）主机A的TCP收到此报文段后，还要向B给出确认，其确认号为y+1
& & &4）主机A的TCP通知上层应用进程，连接已经建立，当主机B的TCP收到主机A的确认后，也通知上层应用进程，连接建立。
2.TCP连接的释放
& & &在数据传输完毕之后，通信双方都可以发出释放连接的请求。释放连接的过程为如上图所示：
& & &1）数据传输结束后，主机A的应用进程先向其TCP发出释放连接请求，不在发送数据。TCP通知对方要释放从A到B的连接，将发往主机B的TCP报文段首部的终止比特FIN置为1，序号u等于已传送数据的最后一个字节的序号加1。
& & &2）主机B的TCP收到释放连接通知后发出确认，其序号为u+1，同时通知应用进程，这样A到B的连接就释放了，连接处于半关闭状态。主机B不在接受主机A发来的数据；但主机B还向A发送数据，主机A若正确接收数据仍需要发送确认。
& & &3）在主机B向主机A的数据发送结束后，其应用进程就通知TCP释放连接。主机B发出的连接释放报文段必须将终止比特置为1，并使其序号w等于前面已经传送过的数据的最后一个字节的序号加 1，还必须重复上次已发送过的ACK=u+1。
& & &4）主机A对主机B的连接释放报文段发出确认，将ACK置为1，ACK=w+1, seq=u+1。这样才把从B到A的反方向连接释放掉，主机A的TCP再向其应用进程报告，整个连接已经全部释放。
3.注意的问题
三次握手建立连接时，发送方再次发送确认的必要性
主要是为了防止已失效的连接请求报文段突然又传到了B,因而产生错误。假定出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间滞留了，一直延迟到连接释放以后的某个时间才到达B，本来这是一个早已失效的报文段。但B收到此失效的连接请求报文段后，就误认为是A又发出一次新的连接请求，于是就向A发出确认报文段，同意建立连接。假定不采用三次握手，那么只要B发出确认，新的连接就建立了，这样一直等待A发来数据，B的许多资源就这样白白浪费了。
四次挥手释放连接时，等待2MSL的意义
第一，为了保证A发送的最有一个ACK报文段能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN和ACK报文段的确认。B会超时重传这个FIN和ACK报文段，而A就能在2MSL时间内收到这个重传的ACK+FIN报文段。接着A重传一次确认。
第二，就是防止上面提到的已失效的连接请求报文段出现在本连接中，A在发送完最有一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。
4.TCP的有限状态机
& & &连接的建立和释放所要求的步骤可以用一个有限状态机来表达，该状态机有11种状态。每一种状态中都存在一些合法的事件，当合法事件发生的时候，可能需要采取某个动作。当其他事件发生的时候，则报告一个错误。
关闭状态，没有连接活动或正在进行
监听状态，服务器正在等待连接进入
收到一个连接请求，尚未确认
已经发出连接请求，等待确认
ESTABLISHED
连接建立，正常数据传输状态
FIN WAIT 1
（主动关闭）已经发送关闭请求，等待确认
FIN WAIT 2
（主动关闭）收到对方关闭确认，等待对方关闭请求
TIMED WAIT
完成双向关闭，等待所有分组死掉
双方同时尝试关闭，等待对方确认
CLOSE WAIT
（被动关闭）收到对方关闭请求，已经确认
（被动关闭）等待最后一个关闭确认，并等待所有分组死掉
TCP建立与释放的变迁如图所示：
客户进程变迁的过程（粗实线）
连接建立：设一个主机的客户进程发起连接请求（主动打开），这时本地TCP实体就创建传输控制快（TCB），发送一个SYN为1的报文，进入SYN_SENT状态。当收到来自进程的SYN和ACK时，TCP就发送出三次握手中的最后一个ACK，进而进入连接已经建立的状态ESTABLISHED。
连接释放：设运行客户进程主机本地TCP实体发送一个FIN置为1的报文，等待着确认ACK的到达，此时状态变为FIN_WAIT_1。当运行客户进程主机收到确认ACK时，则一个方向的连接已经关闭。状态变成FIN_WAIT_2。当运行客户进程的主机收到运行服务器进程的主机发送的FIN置为1的报文后，应响应确认ACK时，这是另一个连接关闭。但此时TCP还要等待一段时间后才删除原来建立的连接记录。返回到初始的CLOSED状态，这是为了保证原来连接上的所有分组都从网络中消失了。
服务器进程变迁的过程（粗虚线）
连接建立：服务器进程发出被动打开，进入监听状态LISTEN。当收到SYN置为1的连接请求报文后，发送确认ACK，并且报文中的SYN也置为1，然后进入SYN_RCVD状态。在收到三次握手最后一个确认ACK时，就转为ESTABLISHED状态。
连接释放：当客户进程的数据已经传送完毕。就发出FIN置为1的报文给服务器进程，进入CLOSE_WAIT状态。服务器进程发送FIN报文段给客户进程，状态变为LAST_ACK状态。当收到客户进程的ACK时，服务器进程就释放连接。删除连接记录。回到原来的CLOSED状态。
阅读(...) 评论()结合Wireshark捕获分组深入理解TCP/IP协议栈之TCP协议(TCP报文格式+三次握手实例)
我的图书馆
结合Wireshark捕获分组深入理解TCP/IP协议栈之TCP协议(TCP报文格式+三次握手实例)
分类： 系统运维转http://blog.chinaunix.net/uid-9112803-id-3212041.html
&&本文简单介绍了TCP面向连接理论知识，详细讲述了TCP报文各个字段含义，并从Wireshark俘获分组中选取TCP连接建立相关报文段进行分析。
&&TCP是面向连接的可靠传输协议，两个进程互发数据之前需要建立连接，这里的连接只不过是端系统中分配的一些缓存和状态变量，中间的分组交换机不维护任何连接状态信息。连接建立整个过程如下(即三次握手协议)：
首先，客户机发送一个特殊的TCP报文段；
其次，服务器用另一个特殊的TCP报文段来响应；
最后，客户机再用第三个特殊报文段作为响应。
图1 三次握手协议示意图[1]
二、TCP报文格式
为了提供可靠的数据传输，TCP报文首部字段有较多的字段，TCP报文格式如下图：
图2 TCP报文格式
源和目标端口
&&用于多路复用/多路分解来自或送至上层应用的数据，可以这样理解，端口用来标识同一台计算机的不同进程。
序列号和确认号
&&这两个字段是TCP可靠传输服务的关键部分，序列号是该报文段首字节的字节流编号(TCP把数据看成是有序的字节流，TCP隐式地对数据流的每个字节进行编号)。这样理解可能更直观，当报文被分解成多个报文段时，序列号就是报文段首字节在整个报文的偏移量。确定号指定下一个期待的字节。TCP是全双工的，假设从主机A接收到主机B的数据，则主机A填充进报文段的确认号是主机A期望从主机B收到的下一个字节序号。还没理清这两者的关系？见下图(三次握手)：
图3 正常情况下TCP连接建立过程
首部长度(4位)
&&因为选项是不定长的，这就需要标识整个首部字段的长度(单位是32位字)，即5+选项个数。4位，单位是32位字，所以首部最长是15*4=60字节，即选项最长是40字节(10个选项)。
&&指示报文段里存在着被发送方的上层实体标记为"紧急"数据，当URG=1时，其后的紧急指针指示紧急数据在当前数据段中的位置(相对于当前序列号的字节偏移量)，TCP接收方必须通知上层实体。
&&当ACK=0时，表示该数据段不包含确认信息，当ACK=1时，表示该报文段包括一个对已被成功接收报文段的确认。
&&当PSH=1时，接收方在收到数据后立即将数据交给上层，而不是直到整个缓冲区满。
&&用于重置一个已经混乱的连接(如主崩溃)，也可用于拒绝一个无效的数据段或者拒绝一个连接请求。一般而言，如果你得到的数据段被设置了RST位，那说明你这一端有问题了。
&&用于建立连接过程，在连接请求中，SYN=1和ACK=0表示该数据段没有使用捎带的确认域，而连接应答捎带一个确认，即SYN=1和ACK=1。
& &&注：捎带是指对客户机到服务器数据的确认被装载在一个承载服务器到客户机的数据报文段中。
&&用于释放一个连接，表示发送方已经没有数据要传输了。此时，接收方可能继续接收数据，好在SYN和FIN数据段都有序列号，从而保证了这两种数据段以正确顺序被处理。
&&用于流控制(确保连接的任何一方都不会过快地发送过量的分组而淹没另一方)，窗口大小指定了从被确认的字节算起可以发送多少个字节。
&&提供了额外可靠性，在计算检验和的时候，TCP的Checksum域设为0，如果数据域的字节数为奇数，则数据域填补一个额外的0字节。校验和算法：将所有的16位字按1的补码形式累加起来，取累加结果的补码。因此，当接收方执行同样计算时(包括Checksum域)，结果应该是0。
&&参考标志字段的URG位。
&&选项部分是为了适合复杂网络环境和更好地服务于应用层设计的。TCP选项最长是40字节。详情见2.2。
&&无任何数据的TCP段也是合法的，通常用于确认和控制信息。
2.2 选项字段[2]
&&TCP选项部分很好出现在已经建立连接的会话中，只要出现在TCP连接建立阶段，即三次握手。TCP选项部分实际运用有以下几种：
(1)最大报文传输段(MMS, Maximum Segment Size)
&&用于发送发与接收方协商最大报文段长度(仅仅是净荷数据，不包括TCP首部字段)。TCP在三次握手中，每一方都会通告期望收到的MSS(MSS只出现在SYN数据包中)，如果一方不接受另一方的MSS值，则使用默认的536字节净荷数据，即主机能够接受20+536字节的TCP报文段。
(2)窗口扩大选项(Window scaling)
&&TCP报文的窗口大小字段占16位，即最大值是65535，但随着时延和带宽比较大的通信产生(如卫星通信)，需要更大的窗口满足性能和吞吐率，这就是窗口扩大选项存在的意义。例子见参考资料[2]。
&&Windows scaling占3个字节，最后一个字节是移位值(Shift
count)，即首部的窗口位数16向左移动，如移位值为14，则新的窗口最大值增大到6)。
&&窗口扩大选项是在TCP建立之初进行协商，如果已实现了窗口扩大，当不再需要扩大窗口时，发送移位值=0就可以恢复到原窗口大小，即65535。
(3)选择确认选项(SACK, Selective Acknowledgements)
&&考虑这样情况，主机A发送报文段12345，主机B收到135且报文无差错，SACK用来确保只重传缺少的报文段，而不是重传所有报文段。
&&SACK选项需要2个功能字节，一个用来指明使用SACK选项(SACK Permission)，另一指明这个选项占多少字节。
&&那怎么形容丢失的报文段2，说明2的左右边界分别是1、3。TCP的数据报文是有字块边界的，而这种边界是由序列号表示的。
&&最多能指明多少个字节块的边界信息呢？答案是4个。这是因为选项字段最大是40字节，去除2个功能字节，序列号是32位即4字节，并且需要左右边界，所以(40-2)/8
(4)时间戳选项(timestamps)
&&时间戳选项用来计算往返时间RTT，发送方在发送报文段时把当前时钟的时间值放入时间戳字段，接收方将该时间戳字段的值复制到确认报文中，当接收方收到确认报文，对比确认报文的时间戳(等于发送方发送报文段的时间戳)和现在的时钟，即可算出RTT。
&&时间戳选项还可用于防止回绕序号PAWS。序列号只有32位，每2^32个序列号就会回绕(想想环形队列)，采用时间戳选项很容易区分相同序列号的报文段。
(5)NOP(NO-Operation)
&&TCP的头部必须是4字节的倍数，而大多数选项不是4字节倍数，不足的用NOP填充。除此之外，NOP也用于分割不同的选项数据，如窗口扩大选项和SACK之间使用NOP隔离(下面的实例将看到这一点)。
三、实例解析
&&还是以访问百度首页为例，首先用DNS协议将URL解析成IP地址，接着在客户机和服务器间建立TCP连接，用Wireshark俘获的分组如下图：
图4 Wireshark俘获建立TCP连接分组
&&你一看会觉得有些奇怪，理论上应该是3个分组的，怎么有6个分组？先不急，先把这6个报文收发示意图作出来(结合时间和报文含义)，如下：
图5 TCP连接建立实例
&&从图可知，连接建立伊始，客户机发了两个报文段，这也许是为了更快建立连接(假设有个请求报文段丢失，也不至于要等一段时间，重发报文)。接下来，以19、21、22(上图红色线条所示)分析TCP连接建立过程。
3.1 第一次握手19
Wireshark俘获TCP连接第一次握手的报文段如下：
图6 TCP连接第一次握手实例
这里主要挑几个字段分析：
&&标志字段，SYN=1、ACK=0表示该数据段没有使用捎带的确认域。
&&最大报文段长度(MMS)1460是怎么来的，链路层的以太网物理特性决定数据帧长度为1500(即MTU，最大传输单元)，(IP首部长度)-20(TCP首部长度)。不要被该报文首部长度32字节所迷惑，这只是建立连接过程。MSS与MTU关系见下图[2]：
图7 MSS与MTU关系
&&NOP字段，可以作为不足4倍数字节填充，也可作为选项间分隔，该报文段出现了3个NOP，具体功能见下图：
图8 TCP报文NOP字段
3.3 第二次握手21
&&服务器响应客户端TCP报文段，此时确认号为1了，SYN=1、ACK=1表明连接应答捎带一个确认，Wireshark俘获分组如下：
图9 TCP连接第二次握手实例
&&为什么MSS是1452而不是1460?这是因为使用PPPoE(Point-to-Point over
Ethernet，可以使以太网的主机通过一个简单的桥接设备连到一个无端的接入集中器上[3])拨号上网，PPoP首部是8个字节，所以PPPoE的MTU是1492，MSS也就为2。
&&那么，TCP连接建立后数据传输的MSS是多少呢，1460 or 1452 or 536 ？我的理解是默认值536，这样理解对吗？求指点！
3.4 第三次握手22
&&客户机再次服务器的报文段，此时序列号和确认号都为1，没有选项字段，Wireshark俘获的分组信息如下：
图10 TCP连接第三次握手实例
&&值得注意的，因为窗口扩展大小协商未果，所以就不扩大窗口了，即窗口大小最大为65535。
如此，TCP连接建立:-)
TA的最新馆藏[转]&[转]&}