TCP 报头格式

TCP 报头格式（精选7篇）

TCP 报头格式 篇1

TCP协议头最少20个字节，包括以下的区域

TCP源端口(Source Port)：16位的源端口其中包含初始化通信的端口。源端口和源IP地址的作用是 标示报问的返回地址。

TCP目的端口(Destination port)：16位的目的端口域定义传输的目的。这个端口指明报文接收计算 机上的应用程序地址接口。

TCP序列号（序列码,Sequence Number）：32位

TCP应答号(Acknowledgment Number)：32位的序列号由接收端计算机使用，重组分段的报文成最初形式。，如果设置了ACK控制位，这个值表示一个准备接收的包的序列码。

数据偏移量(HLEN)：4位包括TCP头大小，指示何处数据开始。

保留(Reserved)：6位值域，这些位必须是0。为了将来定义新的用途所保留。

标志(Code Bits)：6位标志域。表示为：紧急标志、有意义的应答标志、推、重置连接标志、同步序列号标志、完成发送数据标志。按照顺序排列是：URG、ACK、PSH、RST、SYN、FIN。

1.URG：紧急标志

紧急(The urgent pointer)标志有效。紧急标志置位，2.ACK：确认标志

确认编号(Acknowledgement Number)栏有效。大多数情况下该标志位是置位的。TCP报头内的确认编号栏内包含的确认编号(w+1，Figure：1)为下一个预期的序列编号，同时提示远端系统已经成功接收所有数据。3.PSH：推标志

该标志置位时，接收端不将该数据进行队列处理，而是尽可能快将数据转由应用处理。在处理 telnet 或rlogin 等交互模式的连接时，该标志总是置位的。4.RST：复位标志

复位标志有效。用于复位相应的TCP连接。5.SYN：同步标志

同步序列编号(Synchronize Sequence Numbers)栏有效。该标志仅在三次握手建立TCP连接时有效。它提示TCP连接的服务端检查序列编号，该序列编号为TCP连接初始端(一般是客户端)的初始序列编号。在这里，可以把TCP序列编号看作是一个范围从0到4，294，967，295的32位计数器。通过TCP连接交换的数据中每一个字节都经过序列编号。在TCP报头中的序列编号栏包括了TCP分段中第一个字节的序列编号。6.FIN：结束标志

带有该标志置位的数据包用来结束一个TCP回话，但对应端口仍处于开放状态，准备接收后续数据。

窗口(Window)：16位，用来表示想收到的每个TCP数据段的大小。

校验位(Checksum)：16位TCP头。源机器基于数据内容计算一个数值，收信息机要与源机器数值 结果完全一样，从而证明数据的有效性。

优先指针（紧急,Urgent Pointer）：16位，指向后面是优先数据的字节，在URG标志设置了时才有效。如果URG标志没有被设置，紧急域作为填充。加快处理标示为紧急的数据段。

选项(Option)：长度不定，但长度必须以字节。如果 没有 选项就表示这个一字节的域等于0。

数据（Date）：应用程序的数据。

TCP 报头格式 篇2

随着传统媒体市场与网络服务越来越紧密的融合, 流媒体传播和使用日益广泛。流媒体在播放前并不下载整个文件, 只将开始的部分内容存入内存, 随时传送随时播放数据流, 用户不必等到整个文件全部下载完毕, 只需经过几秒或几十秒的启动延时, 即可在计算机上播放, 文件剩余部分将在后台服务器继续下载。流媒体技术在宽带网络中有着广泛的应用, 包括视频点播VOD (Video On Demand) 、视频直播[1,2,3]、视频会议 (Video Conference) 、远程教育 (Distant Education) 和数字图书馆 (Digital Library) 等。

在国内现有的IPTV系统中, 直播流媒体系统得到了广泛的运用。由于IPTV一般都部署在高带宽的局域网中, 因此可以保证提供给用户的都是高码率的影片。然而对于ADSL等宽带网用户由于网络带宽的限制无法接收高码率的影片内容, 所以有必要在高码率的媒体文件基础上进行实时的编码从而降低码率以适应广域网上的网络传输。由于目前的编码格式发展非常迅速, 不同编码格式的应用各不相同, 譬如视频编码的H.264格式压缩比很高, 但是对CPU要求较高, wmv格式的压缩比低于H.264, 但是对CPU的要求不高, 因此根据不同的用户机器配置, 流化系统可实时编码成不同编码格式的媒体数据是必须的。然而基于广域网的流媒体业务的开展还存在着一些技术上有待改善的问题, 比如传输信道网络带宽波动较大, 误码率较高, 延迟抖动较剧烈, 对流媒体服务高带宽低延时的要求而言是一大挑战;另外, 考虑到宽带用户数量增长迅速, 要求流媒体系统具有较好的可扩充性。因此我们设计开发了一套高性能的流媒体直播系统, 该系统包括流媒体服务器、Windows平台的媒体播放器、以及实时编码的流化服务器。我们的服务器系统采用了适合流媒体传输的具有较高压缩比的音视频编码格式 (H264、AMR、wmv、wma) , 利用RTP (real-time transport protocol) /TCP协议[4,5]提供高效可靠的传输服务, 并具有较大规模并发服务的能力和良好的可扩充性。

1系统架构

我们的直播系统分以下为四个部分:各部分的功能为:

· 客户端播放器 负责在PC终端上接收和显示音视频数据, 以及与服务器的点播交互;

· 主控服务器 负责直播交互、访问控制、和负载均衡;

· 播放服务器 负责读取和发送音视频数据;

· 流化服务器 负责将MPEG2格式的TS流数据转换为低码率的媒体流, 供直播服务器使用。

本文主要集中探讨流化服务器和播放服务器的设计实现。

图1是具体的系统示意图。主控服务器和客户端交互通过RTSP (Real Time Streaming Protocol) 传输协议[6], 和播放服务器交互通过TCP连接和私有应用层协议。在后台, 流化服务器将MPEG-2格式的TS流数据进行实时编码及传输处理, 通过UDP上传到播放服务器数据接收及存储模块进行内容存储, 为以后客户端的时移操作进行索引, 由播放服务器接收到主控发来的指令对客户端通过TCP传输媒体数据。

2流化服务器

2.1DirectShow技术在流媒体上的应用

作为Windows平台上进行流媒体处理的开发包, DirectShow集成了DirectX 家族中其他成员如DirectDraw、DirectSound 等的音视频采集, 以及各种格式媒体文件回放的技术。DirectShow 适合处理任意类型的“流式”数据。DirectShow 使用一种叫FILTER GRAPH 的可视化模型来管理整个数据流的处理过程, 参与数据处理的各个功能模块叫做FILTER (COM组件) , DirectShow运用了COM组件技术, Filter 就是DirectShow中一个具有独立功能的COM组件, 以DLL (动态链接库) 的形式提供服务。Filter 按照功能分为三类: Source Filters (负责从文件、采集卡、数字摄像机等数据源取得数据并向下传输) , Transform Filters (负责数据的格式转换和传输) 和Rendering Filters (负责将数据传输出到声卡、显卡或文件) 。各个Filter 在Filter Graph 中按照一定顺序串连起来, 流水线似的协同工作。

DirectShow提供开放式开发环境, 可以定制自己需要的特定功能的Filter。应用程序要按照一定的意图建立起相应的Filter Graph, 然后通过Filter Graph Manager 来控制整个数据处理过程。DirectShow能在Filter Graph 运行的时候接收到各种事件, 并通过消息的方式发送到我们的应用程序。这样, 就实现了应用程序与DirectShow系统之间的交互。

2.2流化系统设计

整套流化系统基于Directshow的平台, 通过不同功能的filter模块实现实时的编码以及传输, 主要分为三个阶段:

1) 数据源采集模块 我们的原始数据源是通过卫星接收器采集到的MPEG-2 TS流, 码率在2Mbps。通过VLC软件将其输出到一个组播地址上作为采集的输入源, 这样如果多个流化系统都需要共享该条数据流, 只要加入该组播地址就可以实现, 从而节省了服务器的负载。接下来采用了MPEG-2 Multicast Receiver这个filter来采集MPEG-2 TS流数据, 然后通过MPEG-2 Demultiplexer这个filter对该TS流进行解复用, 从而分成了音、视频两条数据流, 至此整个数据采集及解复用过程结束, 交给编码模块进行下一步操作。

2) 编码模块 由于数据采集模块生成了音, 视频两条MEPG-2数据流, 在编码模块我们对音、视频分别进行编码, 在做编码前, 对原来采用MPEG-2编码格式的音视频先进行解码, 产生两条raw data, 由于H.264具有高的压缩效率, 这样可以满足较窄的带宽需求, 将H.264 codec通过filter封装起来, filter的输入pin与视频采集源输出pin相连。音频采用AMR (自适应多速率) 进行编码, 作为第三代移动通信及第二代改进的移动通信的编码标准。由于它能在广泛的传输条件下提供高品质的语音效果, 所以整个流化系统采用AMR来进行音频编码, 同视频编码方式一样, 将AMR codec通过filter封装起来, filter的输入pin与音频采集源的输出pin相连。

3) 传输模块 该模块主要负责将编码模块产生的音视频数据发送给数据接收及存储模块。我们知道流媒体系统多采用RTP协议来传输数据, 所以采用将音视频打成RTP包发送, 考虑到实际网络的MTU的限制 (RTP数据包的大小不能超过MTU) , 大多数视频帧, 尤其是I帧需要打成多个RTP数据包进行发送, 因此采用的是以帧为单位, 分别对每一帧进行多个RTP打包。然后通过缓冲区控制调度算法发送数据给数据接收及存储模块。

整个流化系统的流程图如图2所示。

4) 数据管理模块 该模块负责对数据源选择以及对音视频数据选择不同的编码器。由于我们的数据源基本以从卫星信号采集到的电视节目为主, 为此该模块将不同的频道信息搭建如图2所示的directshow管线, 从而解决了对多数据源的支持。

虽然H.264对视频压缩的压缩比很高, 比较适合流媒体, 但是经过测试客户端在对H.264解码时会占用较高的CPU, 对于性能较差的PC机, 过高的CPU占用率会影响到视频正常的回放, 而且过高的CPU占用会消耗过多的系统资源从而影响网络连接速度, 导致数据接收会发生阻塞, 影响服务器正常发送数据。相比较H.264编码器, 微软的wmv/wma编码器虽然压缩比没有H.264那么高, 编码后的画面质量不及H.264清晰, 但是能保证低性能的PC客户端在解码时不会消耗过高的CPU, 为此该模块的作用主要为流化服务器搭建不同音视频编码器的directshow管线。对于不同的PC客户端, 在发送数据前首先通过我们自主的播放器将该PC的CPU及内存的基本信息发送给播放服务器, 然后播放服务器将该信息传递给数据管理模块, 根据不同CPU的性能及内存大小选择适合其正常播放的directshow管线。

3播放服务器

播放服务器主要负责从数据接收及存储模块获取数据, 然后根据不同客户端的播放请求分发音视频数据。由于播放服务器和客户端是一对多的关系, 为了能公平并且尽可能满足每一个客户端能够连续地播放, 对于每一个客户端的连接我们分配了一个发送端buffer实时监控buffer的占有率, 根据不同的buffer占有率, 调整发送策略, 在这里采用round robin调度算法分发数据, 算法如下:

用VTU (virtual time unit) 作为时间片长度, 对于每一个客户端从时间片中分配一部分, 如果在所分配的时间中完成了操作, 则将时间片空余时间闲置, 如果在所分配的时间中未能够完成操作则从其他客户端中空余的时间片中获取时间来完成操作, 这样可以合理地分配好时间来完成给每个客户端发送数据的任务。在每一次发送数据之前, 为每一个client session分配了一个发送buffer, 这部分数据实时从数据接收及存储模块获取。在网络带宽一定的情况下传输占有带宽巨大的视频数据, 网络拥塞是时有发生的, 当缓冲区占有率超过80%时, 就假定它已经开始出现溢出的症状, 这种假定在带宽资源很窄的网络中或在广域网视频传输中尤为合理。在这些情形下, 缓冲区的数据还不一定马上就会被调度出去, 而编码后的视频数据却要不断地进入缓冲区, 如果此时不控制进入缓冲区的速率, 缓冲区就会有溢出的危险。在我们系统中可以通过通知数据编码模块提高帧率从而降低了编码速度从而来缓解缓冲区的压力, 防止缓冲区溢出。当缓冲区占有率低于20%时, 表示当前编码速度要低于数据传输速度, 为此动态地降低视频编码的帧率, 从而提高视频编码速度, 防止缓冲区下溢。一般来说, 当网络带宽确实很宽的情况下, 可以适当将这二个门限提高, 毕竟门限调得过低对视频质量是有影响的。

4系统测试

我们给出服务器性能实验测试的结果。该测试结果可以反映播放服务器在多用户并发的情况下CPU使用率的情况。

将播放服务器架设在一台较高性能的服务器上 (采用双 Intel Xeon 超线程 CPU, 三块千兆网卡) 。为了能够仿真多个客户端PC机同时对服务器发送播放请求, 编写了一个测试工具来模拟多用户的请求, 每一个测试工具最多可以模拟2000个并发用户, 为此我们总共在四台普通PC机上架设了该测试工具来做仿真。测试机和服务器之间组成了一个千兆网络, 四台测试机可以提供近万个用户并发请求。我们采用了二种不同码率的数据来测试。

表1给出了CPU资源与影片码率及用户并发数的关系, 从表中可以看出, 在同一码率下, 资源消耗量与并发用户数呈线性增长关系;在不同码率下, 其增长速度有所不同, 码率越高, 单用户所消耗的系统资源也越高, 增长速度就越高, 而在相同系统资源下, 所获得的最高并发用户数就越低。

5结论

本文给出了一个针对高码率的MPEG-2数据采用不同编码器实时编码来获取低码率的音视频数据, 从而在广域网环境下进行数据传输的流媒体系统。该系统可以根据PC客户端的性能采取不同编码器并且采用缓冲区控制算法, 实时调整编码帧率从而保证数据正常发送。该系统架构合理, 具有可扩展性好、并发性能高、传输质量较为可靠的特点, 适合于广域网应用。

在广域网传输中, 如何解决TCP重传延时的影响我们会在后续工作中进行研究。

参考文献

[1]Zhong Yuzhuo, Xiang Zhe, Shen Hong.Video streaming and video serv-er[M].Beijing:Tsinghua University Press, 2003:1-82.

[2]Ye Dejian, Xu Liangji, Zhang Zuo.Characteristictimesequence based BIBO stability analysis for video streaming buffer control p roblems[C]//In:ACMSIGCOMM (Special Interest Group on Data Commu-nication) AsiaWorkshop.Beijing:China, 2005.

[3] Ye Dejian, Wu Qiufeng, Zhang Zuo.Receiverbufferdriven app roach to adap tive Internet video streaming[J].Electronics Letters, 2002, 38 (22) :1405-1406.

[4]Stevens W R.TCP/IP Illustracted Volume 1:The Protocols[M].Addi-son Wesley, 2000.

[5]Schulzrinne H, Casner S.RTP:A Transport Protocol for Real-Time Ap-plications[S].IETF, RFC3550.

小星星乐园的报头制作(教案) 篇3

第1课 “小星星乐园”的报头制作

教学目的要求：

1、学习用Word 2000制作电子报刊的报头，知道报头主要是由报头字和装饰图案组成。

2、利用“文件”→“页面设置”菜单，设置报刊版面大小。

教学重点：

利用“文件”→“页面设置”菜单，设置报刊版面大小。教学难点：

学习用Word 2000制作电子报刊的报头，知道报头主要是由报头文字和装饰图案组成。

教学准备：计算机

教学过程：

导入新课

出示：“小天使世界”报

提问：这张报叫什么名字？你对这张报的哪个内容感兴趣？

讲述：这是“小天使世界”报的报头。报刊的版头有报头、刊 头两种，报头通常位于报刊的第一版，是报刊中的重要部分。这一课我们主要讲解报头的制作。报头主要是由报头字和装饰图案组成。报头字由报名和报刊说明组成。刊号说明主要包括主办单位、刊号、邮发代号、主编、日期、期数和定价等。今天，我们学习用Word 2000制作电子报刊的报头。

学习新课

出示右侧图标： 提问：谁知道这是什么软件的图标？（Word）

谈话：本节课，我们学习用Word 2000制作电子报刊的报头。报头的结构非常重要，要紧凑、均衡、灵活地把散开的各部分有机地组合在一起。为了设计出一幅好的报头，平时要多收集有关资料和掌握一些与报刊内容有关的知识。

一、学习设置报刊版面大小

谈话：你想出个多大版面的报纸？让我们共同设置一个B5纸型的报刊版面吧！

1、教师边讲述，边演示设置B5纸型的方法：

①

启动Word，选择“文件”→“页面设置”菜单命令，弹出“页面设置”对话框，打开“页边距”选项卡。

②通过“上”、“下”、“左”、“右”4个页边框右边的“增减”按钮，控制纸张留白。

③打开“纸型”选项卡，出现下图

④单击“纸型”下拉列表框右边的按钮▼，通过垂直滚动条，找到并选中“B5”，在“预览”框中观察页面设置效果，如果满意，单击“确定”按钮，完成页面设置。

2、学生操作练习，教师巡视指导。

3、指名上台设置A3纸型，师生共同评价。

4、学生阅读P3说明内容。

巩固、应用

P3 练一练

布置作业

P3 练一练

板书设计：

第1课

“小星星乐园”的报头制作

设置报刊版面大小

1、“文件”→“页面设置”菜单

2、打开“页边距”选项卡

3、打开“纸型”选项卡

第三课时

第1课 “小星星乐园”的报头制作

教学目的要求：

1、学习用Word 2000制作电子报刊的报头，能熟练设置报头字的字体、字号和字体颜色。

2、利用“插入”→“图片”→“来自文件”菜单，插入报头画。教学重点：

利用“插入”→“图片”→“来自文件”菜单，插入报头画，调整图片大小。教学难点：

学会设置图片版式，能灵活运用五种环绕方式。教学准备：计算机 教学过程：

导入新课

出示：“小星星乐园”报头

提问：仔细观察《小星星乐园》报头，你看见了什么？

学生观察后，回答：文字、图片、拼音、背景底图

谈话：这张春天桃花盛开的图片，吴老师很喜爱，所以我把它作为了《小星星乐园》报头画。许多报头都配有报头画，以利突出主题。报头画力求图案简捷、形式多样，大小、位置恰当，与报头文字互相协调。

学习新课

一、指导学生学习添加报头画

1、教师边讲述，边演示添加报头画的方法： ①启动Word，打开文档《小星星乐园》报

②定好插入点，选择“插入”→“图片”→“来自文件”菜单命令，弹出“插入图片”对话框。

③在“查找范围”框中找到图像文件存放的文件夹，在文 件列表框中选中所要添加的图片，单击“插入”按钮，该图片即被 插入到文档中。

④注意新添加的图片会把你排好的画面弄乱，不要慌张。只要设置“图片格式”的版式即可。

二、指导学生学习设置图片版式，能灵活运用五种环绕方式

学生选择“插入”→“图片”→“来自文件”菜单命令，添加报头画。

提问：添加报头画后，出现了什么问题吗？（新添加的图片会把排好的画面弄乱了）我们怎样解决这个问题呢？

学生初次尝试练习，设置图片版式。

指名上台演示本组操作方法，师生共同评价。

教师边讲述，边演示设置图片版式的方法：

①将鼠标指针移到所插入的图片上，单击右键，在弹出的快捷菜单中选择“设置图片格式”命令。

②在“设置图片格式”对话框中，单击“版式”选项卡，将“环绕方式”设置成“浮于文字上方”。

版式

浮于文字上方

学生练习设置图片版式，教师巡视指导。

提问：图片与文字之间有哪几种环绕方式？（嵌入型、四周型、紧密型、衬于文字下方、浮于文字上方）

三、指导学生利用尺寸控制点调整图片的大小

出示：两张对比图片

报头画没放好位置 报头画放好位置

提问：图片版式设置好了，怎样把它调整为合适大小，放在报头右侧？

学习小组自主探究操作练习，教师巡视指导。

学习小组汇报探究结果。

教师边讲述，边演示调整图片大小的方法：

①单击图片，注意观察图片四周的变化。（八个小正方形）

②这八个小正方形是图片的尺寸控制点，通过它们能控制图片的大小。

控制长和宽 移动整张图片 控制长 控制宽

学生练习利用尺寸控制点调整图片的大小,把报头画放好位置。教师巡视指导

巩固、应用

学生阅读P8 说明

练一练 P8 为图1-12报配上报头画

布置作业

练一练 P8 为图1-12报配上报头画

板书设计：

第1课

“小星星乐园”的报头制作

插入报头画：

“插入”→“图片”→“来自文件”菜单，图片与文字之间的环绕方式：

了解TCP IP协议 篇4

TCP IP协议栈：网络接口层

模型的基层是网络接口层。负责数据帧的发送和接收，帧是独立的网络信息传输单元。网络接口层将帧放在网上，或从网上把帧取下来。

TCP IP协议栈：互联层

互联协议将数据包封装成internet数据报，并运行必要的路由算法。这里有四个互联协议：

网际协议IP：负责在主机和网络之间寻址和路由数据包。

地址解析协议ARP：获得同一物理网络中的硬件主机地址。

网际控制消息协议ICMP：发送消息，并报告有关数据包的传送错误，

互联组管理协议IGMP：被IP主机拿来向本地多路广播路由器报告主机组成员。

TCP IP协议栈：传输层

传输协议在计算机之间提供通信会话。传输协议的选择根据数据传输方式而定。两个传输协议：

传输控制协议TCP：为应用程序提供可靠的通信连接。适合于一次传输大批数据的情况。并适用于要求得到响应的应用程序。

用户数据报协议UDP：提供了无连接通信，且不对传送包进行可靠的保证。适合于一次传输小量数据，可靠性则由应用层来负责。

TCP IP协议栈：应用层

应用程序通过这一层访问网络。

网络接口技术

IP使用网络设备接口规范NDIS向网络接口层提交帧。IP支持广域网和本地网接口技术。

串行线路协议

网络须知UDP vs TCP 篇5

这篇教程让我们就从最基本的网络数据收发开始谈起吧，其实这部分才是网络程序员应该做的最基础最简单的部分，但是这部分如果想要做好相对来说还是很有技巧和困难的。而且如果这部分你没做好，在多人对战类游戏中它带来的影响是极其恶劣的。

你可能听说过端口这个概念，也可能知道TCP和UDP这两个概念。在做网络开发的的时候，我们首先要做的就是选择合适的协议。到底是TCP，还是UDP，或者是两者混合来用呢?这是一个问题。

其实来说，你的选择应该和你需要做的游戏类型相关。所以首先如果你是做网络游戏开发的，从现在起，我默认你对一些知名的网络游戏，比如COD,Quake, Unreal, CS已经很熟悉了。

既然我们要谈网络游戏的协议选择，我们就先得对各种协议来个深入的了解，这样到底应该选择那种协议也就不言而喻了。

TPC/IP

TCP

TCP解释为传输控制协议，IP解释为网络协议。他们合起来就完成了你日常网络的大部分工作，比如写email，看网页等。

假如你曾经使用过TCP，那么你肯定知道TCP是可靠协议。即你先在两台机器间建立连接，然后你再在两台机器上开始传输数据，传输的过程和文件读写很像。你在一头写，在另外一头读而已。

TCP协议是可靠而且有序的，这个意味着TCP负责保证你的数据可以完整而且有序的传输到另外一端。TCP是通过流的方式来传输数据的，这就意味这TCP会负责把你的数据切分，打包，然后具体传输。

最后记住，TCP传输其实就和读写文件一样简单。by rellikt

IP

IP协议的抽象简单概念与IP协议底层传输的复杂真实实现形成鲜明对比。

这里不需要任何连接的概念，数据包从一个电脑传输到另外一个电脑，就像你在上课的教室里面传纸条一样。你只要给出一个最终的目的地，包自然会传到那个终端，当然中间还会经过好多层的路由递送。

你完全不能确定自己的包最终会不会到达目的地，只能希望它到达。如果你想知道包最终是否到达，那你就必须让接收者收到以后做出回复。

事实上，整个过程可能还要更复杂一些，由于没有一台机器能够预知包可以最快到达的完整路由途径，所以有时候IP协议会将包复制多份发出，这些包会走不同的路由，因此他们一般也会在不同的时刻到达。

你必须了解因特网路由问题的设计原则是自主组织路径，自主修复路径。所以当你思考问题的底层是如何实现时那是相当带劲的，当然你可以在相关的教科书上找到你想要的内容或者wiki。

UDP

我们已经有一种可以像写文件一样稳定传输数据的方法了，如果我们还想要一种可以自由的收发包的方法，我们可以怎么做呢?

这里我们可以用到UDP。UDP解释为“user datagram protocol”(用户自定义数据协议)。它和TCP类似也是建立在IP协议上的，不过他相比起TCP来在IP协议上只做了薄薄的一层协议。

我们可以使用UDP协议直接对指定的IP和端口发包，比如 1.0.0.127:21(本机的FTP端口)。这个包会从发送者自己路由到接收者手中，当然也有可能半路丢失掉。

在接收端，我们只要侦听相关端口就可以了，当有包从任何电脑发来的时候(这里没有连接的概念)，我们在得到包的数据的同时，也得到了包的发送者的IP和端口数据，发送包的大小。

UDP是不稳定可靠的传输协议，事实上大部分的包是会被送达的，但是你一般会有1%到5%的丢包率。甚至你会发现有段时间，你连一个包都收不到。路由路径上的那些机器出了点啥问题，谁知道呢?

有时候收包的顺序和发包的顺序也是不同的，可能你发包的时候是1,2,3,4,5的顺序发。收到的包就变成1,3,4,5,2的顺序了。当然大部分时候这个顺序是不会乱的。但是这个谁都不敢打保票。

UDP只能保证你一件事，那就是包的完整性。你如果发一个256bytes的包，那么对方收到的肯定也是一个256bytes的包。他不会只收到半个包之类的。当然这其实也是UDP唯一能保证你的事情。其他事情都要靠你自己去订制。 by rellikt

TCP vs UDP

我们现在要做一个选择了。开发游戏到底是用UDP好呢?还是用TCP好呢?

首先我们连列一下他们的有缺点：

TCP：

1. 基于连接的协议。

2. 可靠性和数据包的序列性是有保证的。

3. 自动为你的数据封包。

4. 确保包的流量不会超出你的网络链接的负载上限。

5. 简单易用，你只需要像写文件一样去读写就万事大吉了。

UDP：

1. 没有连接的概念，如果你想要，自己去实现去，

2. 没有关于可靠性和包序列性的保证，包可能会丢失，重复，乱序。

3. 你必须自己去封包。

4. 你必须自己确保自己的数据包不会流量过大从而导致超过链接负载上限。

5. 你必须自己处理包的丢失，重复，乱序的情况，如果你不想他们对你的程序造成麻烦，必须要自己实现代码来做出应对。

这样一比，我们显然应该用那个TCP协议了。它完成了所有我们想要的特性，实在是太完美了，不是吗?by rellikt

TCP的真实工作情况

TCP和UDP都是基于IP协议的，但是他们的本质确实截然不同的。UDP和它底层的IP协议类似，TCP却将很多东西进行了抽象，它使你在使用它的时候感觉就像读写一个文件一样，事实上他对你隐藏了很多复杂功能的实现细节。

它到底是如何实现这些细节的呢?

首先，TCP是流性质的协议，你将数据一个比特一个比特的写入流，然后TCP来确保他们会最终到底目的地。我们必须明确：TCP协议是基于IP协议的，IP协议是基于数据包的。这里TCP其实是把我们的数据流在底层进行了打包。事实上有一些TCP协议中的代码就是把我们的数据流进行排队，然后依次写入包中，当包写入了足够多的数据以后，它就会把包发走。

这里就会导致一些问题，因为你不能控制底层的打包和传输，所以当很小的用户输入数据写入数据流的时候，TCP可能会凑满一定量的数据(比如100bytes)，然后再打包发送。这样的话，在实时性上面就会很差，因为也许你会需要这些包越快到达越好。这些小延迟也许就会大大的影响你的游戏性。

TCP中其实有一个TCP_NODELAY的选项，使用这个选项以后，你的数据就会跳过TCP的队列打包过程，直接发送。

但是即使你使用的这个技术，你在多人网络游戏中还是会遇到不小的问题。

这些问题源自于TCP实现可靠传输的机制。by rellikt

TCP是如何实现可靠传输的

基本上来说，TCP将数据流中的数据做成封包，然后将他们通过不可靠的IP协议发送，然后在接收端重组这些包成为数据流。

但是当一个包丢失的时候TCP会做些什么呢?当包重复和乱序的时候TCP又做了些什么呢?

这里我不想做太深入的介绍，有兴趣的读者可以在wiki上找到他们需要的细节。大致来说，TCP发现丢包的时候，会要求发送者重发，重复的包会被丢弃，乱序包会被排序，事实上他就是这么保证传输的可靠性的。

这里的丢包处理对游戏来说就很糟糕了。TCP中，如果你发现丢包了，必须等待发送者进行重发，在重发的包到来以前，即使有新包来，你也只能让他们在队列里等着，不能读取，这个等待的时间大概是ping值的1.5倍，如果重发的包再次丢失的话那就是3倍的时间。假设你的ping值是125ms，丢包一次就会延迟200ms左右，如果连续丢包就是400ms，这样的情况在大多数即时类游戏中是不能忍受的。

为何你不能选用TCP作为游戏开发的网络协议

通过上面的论述，其实已经很明白了。在注重即时性的游戏中，对于延迟的要求是很苛刻的，我们可以丢包，但是如果我们收到了比丢掉的包更新的包的话，我们完全可以不管丢掉的包。我们只关注当前数据。

这里我们来假设一个最简单的多人游戏的模型。比如一个FPS游戏，你在客户段每次将输入的数据(比如前进，跳跃，开火)发送到服务器端，然后服务器端将玩家当前的位置和情况发回给客户端来做显示。

在这个最简单的模型中，只要有一个包丢失了，所有的东西都必须停下来等包的重发，任何操作都得停掉，你不能移动也不能射击。等到这个包到达的时候，你总算能继续操作了。但是可能你会发现还有一堆等等待重发的包在排队，于是你只好继续等，而且可能你收到的这个重发包对游戏来说已经失去时效性，完全没意义了。这样的游戏你能忍吗?

不幸的是你对TCP协议的这个行为完全无能为力。这是TCP协议的本性，就是它保证了TCP协议的可靠性的。

我们不需要这样无法订制的可靠性协议。我们需要自己进行订制丢包时的处理原则。这也是我们在开发游戏时，避免使用TCP协议的原因。

是否可以混合使用TCP和UDP协议呢?

上面的结论中，我们可以明确知道，一些类似玩家操作，玩家位置的时效性相关数据，我们必须不能使用TCP协议。但是有些数据确是必须保证可靠性的，那我们是否可以使用TCP协议来做同步呢?

这个想法是很好的，我们可以在玩家操作等即时性很强的数据上使用UDP协议，在玩家AI，数据加载，玩家对话等序列性很强的数据上使用TCP。如果你愿意的话，甚至可以为不同的AI创建不同的TCP连接，以免一个AI的丢包会影响的另外一个AI的即时性。

看上去这是一个不错的思路。但是这仅仅是看上去而已。由于TCP和UDP都是基于IP协议的，事实上他们在底层会互相干扰。关于干扰的细节我这里就不详细论述了，想了解的读者可以阅读这篇文章。 by rellikt

结论

TCP 报头格式 篇6

现代移动通信技术和网络技术越来越呈现相融合的趋势。但是在以实时业务为主的移动通信系统中,如何充分利用有限的频谱资源及降低费用的问题向现有IP技术提出了挑战。现有的网络协议中,定义数据报的报头往往很长,报头中有些部分冗余或传输中基本不变,在无线信道上传输时造成了频谱浪费。于是各种IP报头压缩技术出现了。

最先提出的压缩技术针对的是TCP/IP数据报,但是TCP/IP协议并不能支持移动通信中的实时语音业务,因为TCP中的数据报延时对于语音传输来说太大了。因此通常情况下IP语音包括视频业务是通过UDP/IP,再加上一个专门用于传输实时业务的协议RTP来进行的。在此基础上发展起来的压缩技术是CRTP。这种技术可将40或60个字节的IP/UDP/RTP报头最小压缩到2个字节。

但是CRTP在移动通信系统中的表现并不理想,原因在于无线信道较高的误码率使得CRTP产生了过多的丢帧和重传。因此另一种更为健壮的压缩算法被提出,这就是ROCCO(基于压缩的健壮校验和)。该种算法亦可将IP/UDP/RTP报头压缩到很小的长度,重要的是它对信道误码有更好的适应性,达到了在无线信道上通过IP数据流传输实时语音和视频数据的要求。

新的移动通信系统,如第三代移动通信系统WCDMA,已经或即将采用这些IP报头压缩技术。

1 报头压缩原理

1.1 基本思想

通常在一个IP数据流中,IP、TCP、UDP和RTP数据报的报头中很多信息保持不变,或变化很小。这就为压缩提供了基础:发送方只需在开始时传送一个完整的报头,随后不变的部分就可以不传,变化部分可只传送变化的增量;而接收方接收到一个完整的报头后将其保存下来,用于重建随后压缩的数据报。这样就达到了报头压缩的目的。

1.2 报头的字段分类

在压缩前,需要将报头中的各个字段分类,再针对不同的情况采用不同的压缩方法。CRTP算法将报头中的各个字段分为四类:

a) 不变类:假定为不会变化;

b) 增量类:经常变化,但相比前次传送变化很小;

c) 随机类:经常变化且变化不可知;

d) 可推断类:可从其他字段推断而知。

在一个压缩的报头内,不变和可推断类字段没有必要传送。增量类字段只需传送其差值,差值的编码长度一般比原值小的多。而随机类字段却需要按原样传送。以IPv4数据报的报头为例,IPv4报头结构见图1。

属于不变类的有:版本、首部长度、服务类型、标志、片偏移量、寿命、协议、源IP地址、目的IP地址。

属于增量类的有:标识(如果协议字段指明IP后是TCP的话)。

属于随机类的有:标识(其他)。

属于可推断类的有:总长度、首部校验和。

按此分类,CRTP可将IPv4/UDP/RTP总长度40个字节的报头压缩到2个字节。

1.3 压缩流程

压缩总是以压缩端先发送一个含完整报头的数据报开始。在发送前,压缩端已经保存了这个完整报头的所有状态信息“Context”。而这个完整的数据报不同于正常未压缩的数据报,其IP报头部分的长度字段被一个名为“CID”(环境标识)的整数标识替代。该标识唯一指明了保存在压缩端和解压缩端中的状态信息的位置。不同的数据流将被分配不同的CID。

压缩端根据CID和对应的状态信息来压缩数据报。如果报头中不变和可推断类的字段没有发生变化,那么就根据当前的状态信息来压缩数据报,并在压缩后的报头内写入相应的CID。解压缩端收到压缩的数据报后,根据CID找到相应的保存状态信息,再利用它重建数据报头。

当压缩端发现任何不变或可推断类字段发生变化时,将用新的信息来更新状态信息,并再次发送一个含完整报头的数据报到解压缩端。在任何时候,解压缩端收到完整报头数据报都要更新它的状态信息。这样两边才能正常进行压缩和解压缩。

1.4 丢帧处理

通常IP报头压缩协议下层的链路层都有发现传输错误并丢弃错误帧的功能,因此IP报头压缩面对的主要问题是丢帧。TCP/IP报头压缩和UDP/IP报头压缩针对丢帧有不同的处理方法。

压缩的TCP/IP报头中有增量部分(如序号的变化)。不论丢失一个压缩数据报还是完整数据报,解压缩端都将因为状态信息的不同步而错误重建随后的数据报。这些错误重建的数据报不能满足TCP中的校验,因此会被TCP丢弃。TCP发现有数据丢失时,会向对端的TCP发出重发请求。发送端的压缩程序可以通过序号发现TCP在重传数据,这时立即更新自己的状态信息,并发送一个完整的数据报更新解压缩端的状态信息。

压缩的UDP/IP报头中没有增量部分,因此丢失压缩数据报不会在解压缩端造成错误重建随后的数据报,只是简单的丢失了一帧而已。但如果丢失的是为更新状态信息而发送的完整数据报,压缩和解压缩端的状态信息将失去同步。再次同步前,重建的数据报均是错误的,将会被UDP丢弃。为了侦测到有完整数据报丢失,压缩的UDP/IP报头中加入一个“Generation”字段,该字段随着压缩端中状态信息的更新而改变。只有在丢失了一个包含完整数据报头的帧时,两端的Generation字段才会不同,此时解压缩端可通知压缩端再次发送完整数据报更新状态信息。

问题在于CRTP压缩的不只是UDP/IP报头,还有RTP报头。RTP报中不仅有序号,还有时间戳字段。这些字段均属于增量类,在压缩报头中传送的是差值。结果CRTP和压缩TCP/IP报头有同样的情况,即不管丢失的是压缩数据报还是完整数据报,都会使两端的状态信息失去同步,造成随后的数据报错误重建并被丢弃。为了减少丢帧后两边的状态信息失去同步的时间,CRTP采取了一些措施。例如压缩端定时发送完整数据报更新两边的状态信息等。但是这并不能改善CRTP在无线信道上的性能。移动通信系统中复杂的信道编码和交织不可避免的带来了长延时,单向延时可在100 ms左右。在误码率较高的情况下,一旦传输错误超出信道编码的纠错范围产生丢帧,就会造成大量数据报连续丢失。这是语音等实时业务所不能忍受的。

2 改进型压缩技术

人们需要能够容忍高误码率并且有高压缩率的算法来压缩无线信道上的IP数据。一种比CRTP更健壮的压缩算法出现了,这就是ROCCO(基于校验和的报头压缩)。

ROCCO的基本思想和CRTP相同。它的改进之处在于:解压缩端发现丢帧后将尽力修复状态信息使其和压缩端同步,从而可以正确重建随后压缩的数据报。只有在修复状态信息无效后,解压缩端才会要求压缩端更新状态信息。为实现这一机制,ROCCO压缩的报头中包含一个循环码校验(CRC)字段。该CRC覆盖了原数据报中IP/UDP/RTP的报头,如图2所示。

CRC的采用提供了两点帮助:一是在不需要其他标识的情况下可以方便的检测到丢帧发生。更重要的是它为解压缩端试图修正失去同步的状态信息提供了依据。当然压缩的报头中还包含其他字段的信息用于修复。ROCCO可在最多连续丢失26个数据报的情况下修复状态信息。ROCCO解压缩端的工作机制如图3所示。

ROCCO健壮性的另一表现是:它对不同的数据流和信道进行不同的压缩配置,以达到最佳的性能。现已有了各种针对典型无线信道特征的压缩配置。但是通用压缩配置和专用配置相比,性能上只有轻微损失。

和CRTP相比,ROCCO的压缩效率并不低甚至更好。同时,ROCCO的修复机制大大减少了丢帧后错误重建数据报的情况,极大地消除了无线信道高误码率给压缩带来的负面影响。因此ROCCO更适合应用在现代移动通信系统中的实时IP业务。

3 报头压缩技术在WCDMA系统中的应用

WCDMA的制定组织3GPP (第三代移动通讯伙伴项目) 在制定第三代蜂窝移动通信系统时,已经考虑到IP报头压缩技术。在较早版本的技术标准中,已将TCP/IP和UDP/IP报头压缩技术作为系统中的一部分。在随后的版本中,亦采用高效且健壮的RTP/UDP/IP报头压缩技术,进一步增强了其对实时IP语音和视频业务的支持。

压缩和解压缩的两个端点,一个在UE(用户设备)中,另一个在RNC(无线网络控制器)中。RNC除负责控制小区内和各个UE的连接外,也作为小区和核心网的接口。这样压缩和解压缩端间的距离就不会太大,不会在交互状态信息时产生过长的延时。

不管在哪种通信系统中,要实现报头压缩需要满足两点条件:一是必须工作在全双工模式下,因为压缩和解压缩端要随时交互信息。WCDMA为其提供了两条专用信道或一条专用信道(上行)加一条公共信道(下行)的配置;二是压缩和解压缩运行于链路层之上,需要下层提供错误检测、拆帧组帧、帧长度和类型指示等功能。实际上在WCDMA中,IP报头压缩算法被整合到PDCP(数据报集合协议)部分之内。PDCP工作在RLC(射频连接控制)层之上。RLC不仅提供了拆帧组帧、帧长度和类型指示功能,在其3种工作模式-透明传输、非确认传输和确认传输中,确认传输模式提供了重传纠错的功能,可大大减少丢帧数目。物理层提供了检错和纠错的功能,如果有不可纠正错误,将依次上报到PDCP。可以说WCDMA系统完全符合实现IP报头压缩的要求。

4 两种报头压缩技术在WCDMA中的性能分析

4.1 仿真环境

为了具体考察IP报头压缩技术在WCDMA系统中的性能,需要将其放在仿真环境中进行测试。这里选取CRTP和ROCCO这两种最具代表性的压缩方案。考察范围局限在从RNC到UE的无线信道上,不包括压缩数据报在有线网络的传输情况。压缩端处于RNC中,解压缩端在UE侧。对于ROCCO,考察在两种配置下的性能:第一种是最小压缩报头长度2字节的通用型配置;第二种是最小压缩报头长度1字节的专用型配置。

信源是一个假定连接到RNC的AMR声码器,工作在12.2 kbits/s静音压缩模式。语音和静音间隔呈均值为1 s的指数分布。声码器产生的帧为20 ms,经过RTP/UDP/IP后进入压缩端。

仿真环境中WCDMA无线信道的参数配置如下:

a) 移动速度:3 km/h;

b) 干扰:高斯白噪声;

c) 衰落:室内或室外慢衰落;

d) 扩频因子:128;

e) 信道编码:1/3速率卷积码;

f) 功控:理想快速功控;

g) RLC模式:透明传输。

这里作两点假设:第一,在反向信道(这里是上行信道)上传输的状态信息更新请求不会丢失;第二,从更新请求发出到得到相应的时间为120 ms。这两点假设都是有根据的。第一个假设是状态信息更新请求本来就不常产生,同时也为了在较优的环境下估计两种压缩机制的性能。第二个假设是基于实际蜂窝移动通信系统中延时。

仿真中需要跟踪的几个量分别是:比特误码率、数据报丢失数目、数据报连续丢失数目、压缩报头长度。

4.2 仿真结果

图4描述了数据报丢失率和信道误码率之间的关系。从图4中可以看到随着误码率的增大,CRTP和ROCCO的数据报丢失率都在增大。但不同的是ROCCO数据报丢失率增大的幅度远比CRTP要小。在比特误码率为10-3时,CRTP的报丢失率是ROCCO的8倍左右。原因是,CRTP中一个数据报的丢失将引起随后数据报的连续丢失,而信道延时又加大了其状态信息更新的时间。而ROCCO的自动修复机制在很大程度上抵消了高比特误码率的负面影响。

图5显示了在比特误码率为10-3时,CRTP和ROCCO连续丢失数据报数目的分布情况。从中可以看出,CRTP的连续丢失数据报数目主要分布在6-7个,这是CRTP需要交互才能更新状态信息的结果。由于ROCCO的修复机制,数据报丢失数目基本保持在1个。

图6显示了平均压缩报头长度和信道误码率之间的关系。CRTP中数据报丢失造成压缩和解压缩端的状态信息失去同步。为此压缩端不得不传送完整数据报来更新压缩端的状态信息。因此误码率的增大将使平均压缩报头长度增大。在ROCCO中,同样的状态信息大部分可被修复,使得压缩的数据报得以继续传输,所以其平均压缩报头长度随误码率变化不大。

5 结束语

本文在详细比较CRTP和ROCCO这两种IP报头压缩算法优缺点的基础上,通过在仿真WCDMA无线信道上的实际运行结果,进一步研究了报头压缩技术在移动通信系统中的性能。仿真结果表明,CRTP压缩算法的丢帧率随着信道误码率增大而迅速提高,同时其压缩率也在下降,从而无法满足实时语音的业务的要求。相比之下,ROCCO压缩算法对信道误码率有更高的容忍度。在保持高压缩率的前提下,极大的减小了连续丢失数据报的概率。因此ROCCO是移动通信中传输实时IP业务的更好选择。

参考文献

[1]CASNER S,JACOBSONV.Compressing IP/UDP/RTP head-er for Low-Speed Serial Links[M].RFC 2508,1999.

[2] DEGERMARK M, NORDGREN B, PINK S. RFC 2507, IP Header Compression[M]. RFC 2507, 1999.

[3] JACOBSON V. Compressing TCP/IP headers for low-speed serial links[M]. RFC 1144, LBL, 1990.

[4] JONSSON L E, DEGERMARK M, HANNU H, SVANBRO K. Robust Chechsum-based header Compression (ROCCO)[R]. Internet Draft (work in progress), Ericsson Research, 2000.

[5]DEGERMARK M,HANNU H,JONSSON L E,SVANBROK.CRTP over cellular links[R].Internet Draft(work in pro-gress),Ericsson Research,Lulea University of Technology,1999.

如何解决基本的TCP/IP问题 篇7

无法连接特定的 IP 地址。

无法连接特定的主机名或 NetBIOS 名。

如果无法连接特定的 IP 地址，说明问题与基本连接有关。如果能够连接特定的 IP 地址，但却不能用该 IP 地址的主机名或 NetBIOS 名进行连接，说明问题与名称解析有关。

注意：下面所有的故障排除步骤都适用于 NT 和 平台，但可能不适用于 Win9x平台（Win ME 除外）。但是，诊断和故障排除的基本方法对于所有这些 Windows 操作系统而言都是相同的。

为了确定问题是与基本连接有关，还是与名称解析有关，请按照以下过程判断您能否连接到特定的 IP 地址。

连接到某个 IP 地址

使用相应的 IP 地址和选择的 TCP/IP 程序或实用工具，尝试连接网络上的另一台计算机。Web 浏览器、FTP 和 Telnet 是通过 TCP/IP 连接其他计算机时常用的一些程序和实用工具。

注意：如果您不知道要尝试连接的 Windows NT 或 2000 计算机的 IP 地址，可以在其他计算机的命令提示符处运行 IPCONFIG /ALL 命令。

如果用 IP 地址不能连接到其他计算机，说明这是基本连接问题。请用下文“无法连接到特定的 IP 地址”一节中的信息来解决此问题。如果使用 IP 地址能够连接到该计算机，但不能使用该计算机的主机名或 NetBIOS 名建立连接，则可能是名称解析问题。请用下文“无法连接特定的主机名或 NetBIOS 名”一节中的信息来解决此问题。

无法连接到特定的 IP 地址

请按顺序执行以下各节中的过程。完成每个过程之后，请检查能否使用 IP 地址连接到该计算机。

检查 TCP/IP 配置

在使用 TCP/IP 作为网络协议时，TCP/IP 设置不当（例如，IP 地址不正确或子网掩码不正确）可能会引起通信问题。为了确定 Windows NT 或 2000 是否记录了因 TCP/IP 设置不正确而引起的错误，请检查事件查看器的系统日志，看有没有来源为 TCP/IP 或 DHCP 的任何项。要阅读事件查看器中的某一项，请双击该项。

注意：如果事件查看器记录了 DHCP 错误，则应将其报告给网络管理员。

如果在事件查看器系统日志中收到 TCP/IP 错误，请按照错误信息中的说明解决收到的每个错误。例如，如果收到声明 IP 地址参数不正确的错误，则应验证 IP 地址是否有效。

如果事件查看器系统日志中没有错误，请按照下列步骤操作，以确认所使用的 TCP/IP 配置信息是正确的：

使用 IPCONFIG 命令来确定计算机的基本 TCP/IP 设置。为此，请在命令提示符处键入 ipconfig：

验证 IPCONFIG 命令所显示的 IP 地址和子网掩码对您的计算机来说是否是正确的值。如果您无法确定正确的值是什么，请与网络管理员联系。

Ping 环回地址

使用 PING 命令验证 TCP/IP 是否正常工作。为此，请在命令提示符处键入以下命令来 Ping 环回地址 (127.0.0.1)：

ping 127.0.0.1

您应该收到类似下面的响应：

Pinging 127.0.0.1 with 32 bytes of data:

Reply from 127.0.0.1:bytes=32 time=<10ms TTL=128

Reply from 127.0.0.1:bytes=32 time=<10ms TTL=128

Reply from 127.0.0.1:bytes=32 time=<10ms TTL=128

Reply from 127.0.0.1:bytes=32 time=<10ms TTL=128

如果此时收到错误信息，则表明 TCP/IP 安装不正确。要删除并重新安装 TCP/IP，请按照下列步骤操作：

注意：要完成这些步骤，您必须以具有管理员权限的用户身份登录。

在“控制面板”中，双击“网络”，然后单击“协议”选项卡。

单击选中“TCP/IP 协议”，单击“删除”，然后单击“是”。

单击“关闭”，然后单击“是”重新启动计算机。

以具有管理员权限的用户身份登录。

在“控制面板”中，双击“网络”，然后单击“协议”选项卡。

单击“添加”，单击选中“TCP/IP 协议”，然后单击“确定”。

如果要使用 DHCP，请在出现提示时单击“是”。如果不想使用 DHCP，则单击“否”。

出现提示时，键入 Windows NT 源文件的路径，单击“继续”，然后单击“关闭”。

如果您当前没有使用 DHCP，系统将提示您给出 TCP/IP 配置信息。提供正确的值，然后单击“确定”。如果您不能确定正确的值是什么，请与网络管理员联系。

当系统提示您重新启动计算机时，单击“否”，

如果以前曾安装过 Windows NT Service Pack，在重新启动计算机之前，您需要重新安装 Service Pack。

重新启动计算机。

如果在删除并重新安装 TCP/IP 时收到一条错误信息，您可能需要手动从 Windows NT 注册表中删除 TCP/IP。

Ping 计算机的 IP 地址

如果能够成功 Ping 到环回地址，请尝试 Ping 您自己的 IP 地址，方法是在命令提示符处键入 ping ，其中 是您的计算机的 IP 地址。

注意：如果您不知道计算机的 IP 地址，则可通过在命令提示符处键入 ipconfig 来获得该信息。

您会收到类似下面的响应：

Pinging <###.###.###.###> with 32 bytes of data:

Reply from <###.###.###.###>:bytes=32 time=77ms TTL=28

Reply from <###.###.###.###>:bytes=32 time=80ms TTL=28

Reply from <###.###.###.###>:bytes=32 time=78ms TTL=28

Reply from <###.###.###.###>:bytes=32 time=79ms TTL=28

其中 <###.###.###.###> 是您的计算机的 IP 地址。

如果此时收到错误信息，则说明 Windows NT 和网络适配器之间可能存在通信问题。要解决这一问题，请删除并重新安装网络适配器驱动程序。为此，请按照下列步骤操作：

注意：要完成这些步骤，您必须以具有管理员权限的用户身份登录。

在“控制面板”中，双击“网络”，然后单击“适配器”选项卡。

单击选中您的网络适配器驱动程序，单击“删除”，然后单击“是”。

单击“关闭”，然后单击“是”以重新启动计算机。

以具有管理员权限的用户身份登录。

在“控制面板”中，双击“网络”，然后单击“适配器”选项卡。

单击“添加”，单击选中您的网络适配器驱动程序，然后单击“确定”。

使用所提供的对话框来配置网络适配器，然后单击“确定”。

出现提示时，键入 Windows NT 源文件的路径，单击“继续”，然后单击“关闭”。

当系统提示您给出 TCP/IP 配置信息时，请提供正确的值，然后单击“确定”。如果您不能确定正确的值是什么，请与网络管理员联系。

当系统提示您重新启动计算机时，单击“否”。如果以前曾安装过 Windows NT Service Pack，在重新启动计算机之前，您需要重新安装 Service Pack。

重新启动计算机。

如果在删除并重新安装网络适配器驱动程序后，无法 Ping 到计算机的 IP 地址，请与您的网络适配器制造商联系，验证您的网络适配器使用的 Windows NT 驱动程序是否合适。

清除地址解析协议 (ARP) 高速缓存

地址解析协议 (ARP) 高速缓存是最近解析的 IP 地址的列表，用于指向媒体访问控制 (MAC) 地址映射。MAC 地址是嵌入每个网络适配器中的唯一物理地址。

如果 ARP 高速缓存中有一项不正确，IP 数据报就可能被发往错误的计算机。要显示当前 ARP 高速缓存中的所有映射，请使用 ARP 命令，方法是在命令提示符处键入 arp -a。您会收到“No ARP Entries Found”（未发现 ARP 项）消息（如果 ARP 高速缓存为空），或者类似下面的响应：

Interface:10.1.1.3 on Interface 2

Internet Address     Physical Address     Type

10.1.1.7             08-00-02-06-ed-20    dynamic

10.1.1.254           08-00-02-0a-a3-10    dynamic

要删除 ARP 高速缓存中所有不正确的项，可用以下命令清除所有项：

arp -d

其中 是 ARP 高速缓存中存储的 Internet 地址。对 ARP 高速缓存中的每个项均使用该命令，直到删除所有项为止。

要了解 ARP 命令的语法、选项和用法的更多信息，请在命令提示符处键入 arp -?。

验证默认网关