计算机网络自学笔记:TCP
如果你在学习这门课程，仅仅为了理解网络工作原理，那么只要了解TCP是可靠传输，数据传输丢失时会重传就可以了。如果你还要参加研究生考试或者公司面试等，那么下面内容很有可能成为考查的知识点，主要的重点是序号/确认号的编码、超时定时器的设置、可靠传输和连接的管理。1 TCP连接
TCP面向连接，在一个应用进程开始向另一个应用进程发送数据之前，这两个进程必须先相互“握手”，即它们必须相互发送某些预备报文段，以建立连接。连接的实质是双方都初始化与连接相关的发送/接收缓冲区，以及许多TCP状态变量。
这种“连接”不是一条如电话网络中端到端的电路，因为它们的状态完全保留在两个端系统中。
TCP连接提供的是全双工服务 ，应用层数据就可在从进程B流向进程A的同时，也从进程A流向进程B。
TCP连接也总是点对点的 ，即在单个发送方与单个接收方之间建立连接。
一个客户机进程向服务器进程发送数据时，客户机进程通过套接字传递数据流。
客户机操作系统中运行的 TCP软件模块首先将这些数据放到该连接的发送缓存里 ，然后会不时地从发送缓存里取出一块数据发送。
TCP可从缓存中取出并放入报文段中发送的数据量受限于最大报文段长MSS，通常由最大链路层帧长度来决定(也就是底层的通信链路决定)。 例如一个链路层帧的最大长度1500字节，除去数据报头部长度20字节，TCP报文段的头部长度20字节，MSS为1460字节。
报文段被往下传给网络层，网络层将其封装在网络层IP数据报中。然后这些数据报被发送到网络中。
当TCP在另一端接收到一个报文段后，该报文段的数据就被放人该连接的接收缓存中。应用程序从接收缓存中读取数据流(注意是应用程序来读，不是操作系统推送)。
TCP连接的每一端都有各自的发送缓存和接收缓存。
因此TCP连接的组成包括:主机上的缓存、控制变量和与一个进程连接的套接字变量名，以及另一台主机上的一套缓存、控制变量和与一个进程连接的套接字。
在这两台主机之间的路由器、交换机中，没有为该连接分配任何缓存和控制变量。
2报文段结构
TCP报文段由首部字段和一个数据字段组成。数据字段包含有应用层数据。
由于MSS限制了报文段数据字段的最大长度。当TCP发送一个大文件时，TCP通常是将文件划分成长度为MSS的若干块。
TCP报文段的结构。
首部包括源端口号和目的端口号，它用于多路复用/多路分解来自或送至上层应用的数据。另外，TCP首部也包括校验和字段。报文段首部还包含下列字段:
32比特的序号字段和32比特的确认号字段。这些字段被TCP发送方和接收方用来实现可靠数据传输服务。
16比特的接收窗口字段，该字段用于流量控制。该字段用于指示接收方能够接受的字节数量。
4比特的首部长度字段,该字段指示以32比特的字为单位的TCP首部长度。一般TCP首部的长度就是20字节。
可选与变长的选项字段,该字段用于当发送方与接收方协商最大报文段长度，或在高速网络环境下用作窗口调节因子时使用。
标志字段ACK比特用于指示确认字段中的ACK值的有效性，即该报文段包括一个对已被成功接收报文段的确认。 SYN和FIN比特用于连接建立和拆除。 PSH、URG和紧急指针字段通常没有使用。
•序号和确认号
TCP报文段首部两个最重要的字段是序号字段和确认号字段。
TCP把数据看成一个无结构的但是有序的字节流。TCP序号是建立在传送的字节流之上，而不是建立在传送的报文段的序列之上。
一个报文段的序号是该报文段首字节在字节流中的编号。
例如，假设主机A上的一个进程想通过一条TCP连接向主机B上的一个进程发送一个数据流。主机A中的TCP将对数据流中的每一个字节进行编号。假定数据流由一个包含4500字节的文件组成(可以理解为应用程序调用send函数传递过来的数据长度)，MSS为1000字节(链路层一次能够传输的字节数)，如果主机决定数据流的首字节编号是7。TCP模块将为该数据流构建5个报文段(也就是分5个IP数据报)。第一个报文段的序号被赋为7;第二个报文段的序号被赋为1007,第三个报文段的序号被赋为2007，以此类推。前面4个报文段的长度是1000，最后一个是500。
确认号要比序号难理解一些。前面讲过，TCP是全双工的，因此主机A在向主机B发送数据的同时，也可能接收来自主机B的数据。从主机B到达的每个报文段中的序号字段包含了从B流向A的数据的起始位置。 因此主机B填充进报文段的确认号是主机B期望从主机A收到的下一报文段首字节的序号。
假设主机B已收到了来自主机A编号为7-1006的所有字节，同时假设它要发送一个报文段给主机A。主机B等待主机A的数据流中字节1007及后续所有字节。所以，主机B会在它发往主机A的报文段的确认号字段中填上1007。
再举一个例子，假设主机B已收到一个来自主机A的包含字节7-1006的报文段，以及另一个包含字节2007-3006的报文段。由于某种原因，主机A还没有收到字节1007-2006的报文段。
在这个例子中，主机A为了重组主机B的数据流，仍在等待字节1007。因此，A在收到包含字节2007-3006的报文段时，将会又一次在确认号字段中包含1007。 因为TCP只确认数据流中至第一个丢失报文段之前的字节数据，所以TCP被称为是采用累积确认。
TCP的实现有两个基本的选择:
1接收方立即丢弃失序报文段;
2接收方保留失序的字节，并等待缺少的字节以填补该间隔。
一条TCP连接的双方均可随机地选择初始序号。 这样做可以减少将那些仍在网络中的来自两台主机之间先前连接的报文段，误认为是新建连接所产生的有效报文段的可能性。
•例子telnet
Telnet由是一个用于远程登录的应用层协议。它运行在TCP之上，被设计成可在任意一对主机之间工作。
假设主机A发起一个与主机B的Telnet会话。因为是主机A发起该会话，因此主机A被标记为客户机，主机B被标记为服务器。用户键入的每个字符(在客户机端)都会被发送至远程主机。远程主机收到后会复制一个相同的字符发回客户机，并显示在Telnet用户的屏幕上。这种“回显”用于确保由用户发送的字符已经被远程主机收到并处理。因此，在从用户击键到字符显示在用户屏幕上之间的这段时间内，每个字符在网络中传输了两次。
现在假设用户输入了一个字符“C”，假设客户机和服务器的起始序号分别是42和79。前面讲过，一个报文段的序号就是该报文段数据字段首字节的序号。因此，客户机发送的第一个报文段的序号为42，服务器发送的第一个报文段的序号为79。前面讲过，确认号就是主机期待的数据的下一个字节序号。在TCP连接建立后但没有发送任何数据之前，客户机等待字节79，而服务器等待字节42。
如图所示，共发了3个报文段。第一个报文段是由客户机发往服务器，其数据字段里包含一字节的字符“C”的ASCII码，其序号字段里是42。另外，由于客户机还没有接收到来自服务器的任何数据，因此该报文段中的确认号字段里是79。
第二个报文段是由服务器发往客户机。它有两个目的:第一个目的是为服务器所收到的数据提供确认。服务器通过在确认号字段中填入43，告诉客户机它已经成功地收到字节42及以前的所有字节，现在正等待着字节43的出现。第二个目的是回显字符“C”。因此，在第二个报文段的数据字段里填入的是字符“C”的ASCII码，第二个报文段的序号为79，它是该TCP连接上从服务器到客户机的数据流的起始序号，也是服务器要发送的第一个字节的数据。
这里客户机到服务器的数据的确认被装载在一个服务器到客户机的数据的报文段中，这种确认被称为是捎带确认.
第三个报文段是从客户机发往服务器的。它的唯一目的是确认已从服务器收到的数据。
3往返时延的估计与超时
TCP如同前面所讲的rdt协议一样，采用超时/重传机制来处理报文段的丢失问题。最重要的一个问题就是超时间隔长度的设置。显然，超时间隔必须大于TCP连接的往返时延RTT，即从一个报文段发出到收到其确认时。否则会造成不必要的重传。
•估计往返时延
TCP估计发送方与接收方之间的往返时延是通过采集报文段的样本RTT来实现的，就是从某报文段被发出到对该报文段的确认被收到之间的时间长度。
也就是说TCP为一个已发送的但目前尚未被确认的报文段估计sampleRTT，从而产生一个接近每个RTT的采样值。但是，TCP不会为重传的报文段计算RTT。
为了估计一个典型的RTT，采取了某种对RTT取平均值的办法。TCP据下列公式来更新
EstimatedRTT=(1-)*EstimatedRTT+*SampleRTT
即估计RTT的新值是由以前估计的RTT值与sampleRTT新值加权组合而成的。
参考值是a=0.125，因此是一个加权平均值。显然这个加权平均对最新样本赋予的权值
要大于对老样本赋予的权值。因为越新的样本能更好地反映出网络当前的拥塞情况。从统计学观点来讲，这种平均被称为指数加权移动平均
除了估算RTT外，还需要测量RTT的变化，RTT偏差的程度，因为直接使用平均值设置计时器会有问题(太灵敏)。
DevRTT=(1-β)*DevRTT+β*|SampleRTT-EstimatedRTT|
RTT偏差也使用了指数加权移动平均。B取值0.25.
•设置和管理重传超时间隔
假设已经得到了估计RTT值和RTT偏差值，那么TCP超时间隔应该用什么值呢?TCP将超时间隔设置成大于等于估计RTT值和4倍的RTT偏差值,否则将造成不必要的重传。但是超时间隔也不应该比估计RTT值大太多，否则当报文段丢失时，TCP不能很快地重传该报文段，从而将给上层应用带来很大的数据传输时延。因此，要求将超时间隔设为估计RTT值加上一定余量。当估计RTT值波动较大时，这个余最应该大些;当波动比较小时，这个余量应该小些。因此使用4倍的偏差值来设置重传时间。
TimeoutInterval=EstimatedRTT+4*DevRTT
4可信数据传输
因特网的网络层服务是不可靠的。IP不保证数据报的交付，不保证数据报的按序交付，也不保证数据报中数据的完整性。
TCP在IP不可靠的尽力而为服务基础上建立了一种可靠数据传输服务。
TCP提供可靠数据传输的方法涉及前面学过的许多原理。
TCP采用流水线协议、累计确认。
TCP推荐的定时器管理过程使用单一的重传定时器，即使有多个已发送但还未被确认的报文段也一样。重传由超时和多个ACK触发。
在TCP发送方有3种与发送和重传有关的主要事件:从上层应用程序接收数据，定时器超时和收到确认ACK。
从上层应用程序接收数据。一旦这个事件发生，TCP就从应用程序接收数据，将数据封装在一个报文段中，并将该报文段交给IP。注意到每一个报文段都包含一个序号，这个序号就是该报文段第一个数据字节的字节流编号。如果定时器还没有计时，则当报文段被传给IP时，TCP就启动一个该定时器。
第二个事件是超时。TCP通过重传引起超时的报文段来响应超时事件。然后TCP重启定时器。
第三个事件是一个来自接收方的确认报文段(ACK)。当该事件发生时，TCP将ACK的值y与变量SendBase(发送窗口的基地址)进行比较。TCP状态变量SendBase是最早未被确认的字节的序号。就是指接收方已正确按序接收到数据的最后一个字节的序号。TCP采用累积确认，所以y确认了字节编号在y之前的所有字节都已经收到。如果Y>SendBase,则该ACK是在确认一个或多个先前未被确认的报文段。因此发送方更新其SendBase变量，相当于发送窗口向前移动。
另外，如果当前有未被确认的报文段，TCP还要重新启动定时器。
快速重传
超时触发重传存在的另一个问题是超时周期可能相对较长。当一个报文段丢失时，这种长超时周期迫使发送方等待很长时间才重传丢失的分组，因而增加了端到端时延。所以通常发送方可在超时事件发生之前通过观察冗余ACK来检测丢包情况。
冗余ACK就是接收方再次确认某个报文段的ACK，而发送方先前已经收到对该报文段的确认。
当TCP接收方收到一个序号比所期望的序号大的报文段时，它认为检测到了数据流中的一个间隔，即有报文段丢失。这个间隔可能是由于在网络中报文段丢失或重新排序造成的。因为TCP使用累计确认，所以接收方不向发送方发回否定确认，而是对最后一个正确接收报文段进行重复确认(即产生一个冗余ACK)
如果TCP发送方接收到对相同报文段的3个冗余ACK.它就认为跟在这个已被确认过3次的报文段之后的报文段已经丢失。一旦收到3个冗余ACK，TCP就执行快速重传 ，
即在该报文段的定时器过期之前重传丢失的报文段。
5流量控制
前面讲过，一条TCP连接双方的主机都为该连接设置了接收缓存。当该TCP连接收到正确、按序的字节后，它就将数据放入接收缓存。相关联的应用进程会从该缓存中读取数据，但没必要数据刚一到达就立即读取。事实上，接收方应用也许正忙于其他任务，甚至要过很长时间后才去读取该数据。如果应用程序读取数据时相当缓慢，而发送方发送数据太多、太快，会很容易使这个连接的接收缓存溢出。
TCP为应用程序提供了流量控制服务以消除发送方导致接收方缓存溢出的可能性。因此，可以说 流量控制是一个速度匹配服务，即发送方的发送速率与接收方应用程序的读速率相匹配。
前面提到过，TCP发送方也可能因为IP网络的拥塞而被限制，这种形式的发送方的控制被称为拥塞控制(congestioncontrol)。
TCP通过让接收方维护一个称为接收窗口的变量来提供流量控制。接收窗口用于告诉发送方，该接收方还有多少可用的缓存空间。因为TCP是全双工通信，在连接两端的发送方都各自维护一个接收窗口变量。 主机把当前的空闲接收缓存大小值放入它发给对方主机的报文段接收窗口字段中，通知对方它在该连接的缓存中还有多少可用空间。
6 TCP连接管理
客户机中的TCP会用以下方式与服务器建立一条TCP连接:
第一步: 客户机端首先向服务器发送一个SNY比特被置为1报文段。该报文段中不包含应用层数据，这个特殊报文段被称为SYN报文段。另外，客户机会选择一个起始序号，并将其放置到报文段的序号字段中。为了避免某些安全性攻击，这里一般随机选择序号。
第二步: 一旦包含TCP报文段的用户数据报到达服务器主机，服务器会从该数据报中提取出TCPSYN报文段，为该TCP连接分配TCP缓存和控制变量，并向客户机TCP发送允许连接的报文段。这个允许连接的报文段还是不包含应用层数据。但是，在报文段的首部却包含3个重要的信息。
首先，SYN比特被置为1。其次，该 TCP报文段首部的确认号字段被置为客户端序号+1最后，服务器选择自己的初始序号，并将其放置到TCP报文段首部的序号字段中。 这个允许连接的报文段实际上表明了:“我收到了你要求建立连接的、带有初始序号的分组。我同意建立该连接，我自己的初始序号是XX”。这个同意连接的报文段通常被称为SYN+ACK报文段。
第三步: 在收到SYN+ACK报文段后，客户机也要给该连接分配缓存和控制变量。客户机主机还会向服务器发送另外一个报文段，这个报文段对服务器允许连接的报文段进行了确认。因为连接已经建立了，所以该ACK比特被置为1，称为ACK报文段，可以携带数据。
一旦以上3步完成，客户机和服务器就可以相互发送含有数据的报文段了。
为了建立连接，在两台主机之间发送了3个分组，这种连接建立过程通常被称为 三次握手(SNY、SYN+ACK、ACK，ACK报文段可以携带数据) 。这个过程发生在客户机connect()服务器，服务器accept()客户连接的阶段。
假设客户机应用程序决定要关闭该连接。(注意，服务器也能选择关闭该连接)客户机发送一个FIN比特被置为1的TCP报文段，并进人FINWAIT1状态。
当处在FINWAIT1状态时，客户机TCP等待一个来自服务器的带有ACK确认信息的TCP报文段。当它收到该报文段时，客户机TCP进入FINWAIT2状态。
当处在FINWAIT2状态时，客户机等待来自服务器的FIN比特被置为1的另一个报文段，
收到该报文段后，客户机TCP对服务器的报文段进行ACK确认，并进入TIME_WAIT状态。TIME_WAIT状态使得TCP客户机重传最终确认报文，以防该ACK丢失。在TIME_WAIT状态中所消耗的时间是与具体实现有关的，一般是30秒或更多时间。
经过等待后，连接正式关闭，客户机端所有与连接有关的资源将被释放。 因此TCP连接的关闭需要客户端和服务器端互相交换连接关闭的FIN、ACK置位报文段。
绛旓細TCP鍗忚琚О浣滀竴绉嶇瀵圭鍗忚銆傝繖鏄洜涓哄畠涓轰袱鍙璁＄畻鏈涔嬮棿鐨勮繛鎺ヨ捣浜嗛噸瑕佷綔鐢:褰撲竴鍙拌绠楁満闇瑕佷笌鍙︿竴鍙拌繙绋嬭绠楁満杩炴帴鏃,TCP鍗忚浼氳瀹冧滑寤虹珛涓涓繛鎺ャ佸彂閫佸拰鎺ユ敹鏁版嵁浠ュ強缁堟杩炴帴銆 浼犺緭鎺у埗鍗忚TCP鍗忚鍒╃敤閲嶅彂鎶鏈拰鎷ュ鎺у埗鏈哄埗,鍚戝簲鐢ㄧ▼搴忔彁渚涘彲闈犵殑閫氫俊杩炴帴,浣垮畠鑳藉鑷姩閫傚簲缃戜笂鐨勫悇绉嶅彉鍖栥傚嵆浣垮湪 Internet ...
绛旓細浜掕仈缃戝崗璁氱О涓TCP/IP鍗忚鏃忥紝绠绉癟CP/IP銆傜敱浜庡湪缃戠粶閫氳鍗忚鏅亶閲囩敤鍒嗗眰鐨勭粨鏋勶紝褰撳涓眰娆＄殑鍗忚鍏卞悓宸ヤ綔鏃讹紝绫讳技璁＄畻鏈绉戝涓殑鍫嗘爤锛屽洜姝ゅ張琚О涓篢CP/IP鍗忚鏍堛俆CP/IP鎻愪緵鐐瑰鐐圭殑閾炬帴鏈哄埗锛屽皢鏁版嵁搴旇濡備綍灏佽銆佸畾鍧銆佷紶杈撱佽矾鐢变互鍙婂湪鐩殑鍦板浣曟帴鏀跺姞浠ユ爣鍑嗗寲銆傚畠灏嗛氫俊杩囩▼鎶借薄鍖栦负鍥涗釜鎶借薄灞...
绛旓細杩欓鏈夌偣楹荤儲锛屽叧閿槸鎴戜篃璁颁笉浣忓ご缁撴瀯锛屽鐓у浘璇存槑涓涓嬪惂銆備笅闈㈡槸TCP澶寸粨鏋 涓嬮潰灏辨槸鎸変綅閫愭瑙ｇ瓟灏辫浜嗭紝鐩存帴璇寸瓟妗堬紝浣犺嚜宸卞鐓т竴涓嬨傚彟澶栵紝鐩存帴鐢16杩涘埗浜嗭紝闇瑕佸崄杩涘埗鑷繁鐢璁＄畻鍣绠 1銆0D28鍜0015 2銆505FA908鍜00000000 3銆28B锛岃鏄庝竴涓嬶紝棣栭儴闀垮害鍦ㄨ繖鏄7锛岃〃绀虹殑鏄弻瀛楅暱锛屾晠棣栭儴闀28...
绛旓細TCP/IP鏄湁鍏缃戠粶鎺ュ彛灞傦紝缃戠粶灞傦紝杩愯緭灞傚拰搴旂敤灞傚叡鍥涘眰鍗忚绯荤粺銆傜涓灞傛槸搴旂敤灞傦紝鍔熻兘鏄湇鍔′簬搴旂敤杩涚▼鐨勶紝灏辨槸鍚戠敤鎴锋彁渚涙暟鎹姞涓婄紪鐮佸拰瀵硅瘽瀵圭殑鎺у埗銆傜浜屽眰鏄繍杈撳眰锛屽姛鑳芥槸鑳藉瑙ｅ喅璇稿绔埌绔彲闈犳у拰淇濊瘉鏁版嵁鎸夌収姝ｇ‘鐨勯『搴忓埌杈俱傚寘鎷墍缁欐暟鎹簲璇ラ佺粰鍝釜搴旂敤绋嬪簭銆傜涓夊眰鏄綉缁滃眰锛屽姛鑳芥槸杩涜...
绛旓細1銆傚熀浜庤繛鎺ヤ笌鏃犺繛鎺 2銆傚绯荤粺璧勬簮鐨勮姹傦紙TCP杈冨锛孶DP灏戯級3銆俇DP绋嬪簭缁撴瀯杈冪畝鍗 4銆傛祦妯″紡涓庢暟鎹姤妯″紡 5銆俆CP淇濊瘉鏁版嵁姝ｇ‘鎬э紝UDP鍙兘涓㈠寘锛孴CP淇濊瘉鏁版嵁椤哄簭锛孶DP涓嶄繚璇佸彟澶栫粨鍚圙PRS缃戠粶鐨勬儏鍐靛叿浣撶殑璋堜竴涓嬩粬浠殑鍖哄埆锛1銆俆CP浼犺緭瀛樺湪涓瀹氱殑寤舵椂锛屽ぇ姒傛槸1600MS锛堢Щ鍔ㄦ彁渚涳級锛孶DP鍝嶅簲閫熷害绋嶅井蹇竴浜涖
绛旓細1銆TCP鏄竴绉嶉潰鍚戣繛鎺ョ殑銆佸彲闈犵殑銆佸熀浜庡瓧鑺傛祦鐨勪紶杈撳眰閫氫俊鍗忚锛岀敱IETF鐨凴FC 793瀹氫箟銆傚湪绠鍖栫殑璁＄畻鏈虹綉缁OSI妯″瀷涓紝瀹冨畬鎴愮鍥涘眰浼犺緭灞傛墍鎸囧畾鐨勫姛鑳姐傚湪鍥犵壒缃戝崗璁棌涓紝TCP灞傛槸浣嶄簬IP灞備箣涓婏紝搴旂敤灞備箣涓嬬殑涓棿灞傘備笉鍚屼富鏈虹殑搴旂敤灞備箣闂寸粡甯搁渶瑕佸彲闈犵殑銆佸儚绠￠亾涓鏍风殑杩炴帴锛屼絾鏄疘P灞備笉鎻愪緵杩欐牱鐨勬祦...
绛旓細璁＄畻鏈虹綉缁鍗忚鏈锛歍CP/IP鍗忚 HTTP鍗忚 FTP鍗忚 SMTP鍗忚 DNS鍗忚绛夈俆CP/IP鍗忚锛氭槸Internet鏈鍩烘湰鐨勫崗璁紝涔熸槸鏈閲嶈鐨勫崗璁箣涓銆傚畠鍖呭惈浜嗕竴绯诲垪鍗忚锛屽浼犺緭鎺у埗鍗忚TCP銆佺綉缁滃崗璁甀P绛夈俆CP璐熻矗鏁版嵁鐨勪紶杈擄紝纭繚鏁版嵁鍦ㄤ紶杈撹繃绋嬩腑鐨勫彲闈犳у拰瀹屾暣鎬э紱IP璐熻矗鏁版嵁鐨勮矾鐢卞拰瀵诲潃銆傝繖涓や釜鍗忚鐨勯厤鍚堜娇鐢紝浣垮緱...
绛旓細璇锋敞鎰忥紝鐜板湪TCP杩炴帴杩樻病鏈夐噴鏀炬帀銆傚繀椤荤粡杩囨椂闂寸瓑寰呰鏃跺櫒 锛圱IME-WAIT timer锛夎缃殑鏃堕棿2MSL鍚庯紝A鎵嶈繘鍏ュ埌CLOSED鐘舵併傛椂闂碝SL鍙仛鏈闀挎姤鏂囨瀵垮懡 锛圡aximum Segment Lifetime锛夛紝RFC 793寤鸿璁句负2鍒嗛挓銆備絾杩欏畬鍏ㄦ槸浠庡伐绋嬩笂鏉ヨ冭檻鐨勶紝瀵逛簬鐜板湪鐨缃戠粶锛孧SL锛2鍒嗛挓鍙兘澶暱浜嗕竴浜涖傚洜姝CP鍏佽涓嶅悓鐨勫疄鐜...
绛旓細璁＄畻鏈虹綉缁鍗忚鏄竴缁勮鍒欏拰鏍囧噯锛屽畠浠畾涔変簡璁＄畻鏈哄拰缃戠粶璁惧涔嬮棿杩涜閫氫俊鐨勬柟寮忋傝繖浜涘崗璁负缃戠粶涓殑鎵鏈夎澶囨彁渚涗簡涓绉嶅叡鍚岀殑璇█锛屼娇寰楀畠浠兘澶熺浉浜掔悊瑙ｅ拰鎵ц褰兼鐨勬寚浠ゃ傝绠楁満缃戠粶鍗忚鏈夎澶氱锛屽畠浠悇鑷礋璐ｄ笉鍚岀殑鍔熻兘锛屼互纭繚鏁版嵁鍙互鍦ㄧ綉缁滀腑瀹夊叏銆佹湁鏁堝湴浼犺緭銆備互涓嬫槸涓浜涘父鐢ㄧ殑璁＄畻鏈虹綉缁滃崗璁細1. TC...
绛旓細TCP/IP鏄緵宸茶繛鎺ュ洜鐗圭綉鐨璁＄畻鏈杩涜閫氫俊鐨勯氫俊鍗忚銆俆CP/IP鍗忚TransmissionControlProtocol/InternetProtocol鐨勭畝鍐欙紝涓瘧鍚嶄负浼犺緭鎺у埗鍗忚/鍥犵壒缃戜簰鑱斿崗璁紝鍙堝悕缃戠粶閫氳鍗忚锛屾槸Internet鏈鍩烘湰鐨勫崗璁両nternet鍥介檯浜掕仈缃戠粶鐨勫熀纭锛岀敱缃戠粶灞傜殑IP鍗忚鍜屼紶杈撳眰鐨凾CP鍗忚缁勬垚銆俆CP/IP浼犺緭鍗忚锛屽嵆浼犺緭鎺у埗/缃戠粶...
