1. 計算機網路都是怎樣運行的
鑒於計算機網路規模巨大、聯系面廣、涉及因素多，通常要劃分成各種特定問題，突出主要因素、忽略或弱化次要因素，並進行概括、抽象，建立典型化模型來加以研究
組建計算機網路時，首先要解決的具體問題和理論問題。目的是在滿足應用需求和客觀約束條件下，以最少的投入（包括人力 、物力、財力、時間等)，設計、建造一個安全、可靠 、有效、運行良好 、適應性強、易管理、易維護、易改造、易擴充的計算機網路，並預計回答資金回收期限以及可能獲得的最大的社會效益和經濟效益等問題。優化設計分為 3個階段 ：① 需求分析與規劃階段。應對需求和環境進行調查 ，收集 、整理必要的資料與數據，包括應用目的、信息格式、通信量、響應時間、差錯率、可靠性要求、選用的標准，以及現有設備、用戶分布、地理環境、自然條件 、氣象特徵、外界影響等 ，目的是明確需求、找出關鍵環節、規劃項目的總體輪廓。②網路總體設計階段。在調查分析的基礎上，應根據應用需求，確定網路的總體框架和重要的網路參數，必須對一些重要的關鍵問題做出抉擇，如選用何種拓撲結構，設備的選型、安置和連接方法，通信介質的選擇、線路布局和容量分配，通信規程以及路由、流量和差錯控制技術，網路業務的種類、服務質量及高層協議的選擇等。③設計方案評測階段。根據評測目標。建立各種數學模型（如預測模型、優化模型、性能評價模型等），以便對網路的性能、費用、工期時限、效益概算、資金回收期限等進行分析與評價，給出技術與經濟可行性結論。如果結論達不到預計要求，應視情況，部分或全部進行重新網路優化設計。
網路體系結構編輯
計算機網路體系結構是一組用於規劃、設計、組建計算機網路所需遵循的原則和依據，包括層次結構、功能劃分、協議規范、過程描述等內容。對計算機網路發展最有影響的網路體系結構是國際標准化組織（ISO）建議的開放系統互連（OSI）參考模型 。它是通過體系模型、服務定義和協議規范3 個抽象級別，逐步深入、逐步細化加以制定和描述的。體系結構模型是OSI 最高級別的抽象，它從功能和概念級上建造了一個抽象的、具有層次結構的體系模型，刻畫了開放系統的整體性能 、結構要素 、行為特徵、層次關系 、數據格式等內容 。OSI 體系結構模型由應用層、表示層、會話層、運輸層、網路層、數據鏈路層和物理層等7層組成。服務定義是OSI低一級別的抽象，它更詳細地定義每層提供的服務，規定各層的外特性和層間抽象介面，但不涉及是否實現和如何實現的細節。協議規范是 OSI最低級別的抽象，它精確地定義某層實體為了協同工作和交互活動所需傳送控制信息的語義和語法，以及採用什麼樣的規程去分析、解釋和加工它們。體系結構模型進一步發展趨向是研究、制定網路應用體系結構模型，目的是為網路用戶創造良好的運行環境和開發環境。例如，一些網路專家在 OSI模型的基礎上，提出開放應用體系結構（OAA）模型的設想。OAA由操作環境和開發維護環境兩部分組成。
路徑選擇編輯
早期計算機領域中幾個熱門研究課題，成果多、文獻量大。路徑選擇的主要目的是在網路中選擇最佳路徑 ，將源站點發送的報文信息高速、有效地傳送到目的站點，其側重點是提高網路服務質量、減少延遲時間、降低傳輸費用。衡量路徑選擇演算法好壞的標准包括：①報文信息以最短的時間、最短的路徑或最少的費用，傳送到目的地。②演算法簡單、易於實現、適應性強（能適應網路故障和結構變化所帶來的影響）。③不過重增加網路和結點的開銷（包括處理機時間、存儲容量 、信息傳輸量等)。④有助於改善網路性能、保持穩定的吞吐率、降低平均傳輸延遲時間、均衡網路負載等。典型路徑選擇演算法有擴散式路徑選擇、隨機式路徑選擇、固定路徑選擇、自適應路徑選擇等。
控制內容編輯
流量控制和擁擠控制
流量控制和擁擠控制的目的是控制網路和各條通信線路上的信息流通量，保持網路處於穩定的工作狀態，以便提高網路吞吐率、減少平均延遲時間，其側重點是改善網路工作效率和資源利用率，防止擁塞和死鎖現象發生。流量控制可分為相鄰結點間流控、源結點與目的結點間流控、主機與結點間流控、主機與主機間流控四種類型。常用的控制方法有限定傳輸速率、拒收重傳、暫停發送、限定接收發送窗口大小、預約緩沖區等。用於擁擠控制的方法有預約緩沖區、限制管道流量、入網許可證、反向抑制等。
差錯控制
也是網路設計中的重要研究課題，其目的是根據應用要求、線路質量、設備性能和外界環境等因素，選擇適當的控制機制和方法，查出並糾正信息傳輸中的差錯，將其減少到允許程度之內。計算機網路中，通常採用兩種基本策略來處理信息傳輸中的差錯：①使用糾錯碼。即在要發送的信息報文中附加上足夠多的冗餘信息，使接收方不僅能夠查出、而且能夠糾正信息報文中的差錯。因信息冗餘量過大，且控制復雜，通常用於單向傳輸場合，或用作輔助措施。②使用檢錯碼。即在要發送的信息報文中附加一定的冗餘信息，使接收方能夠查出信息報文中的差錯（但不知什麼樣的差錯），並通知發送方重傳原來的信息報文。通信規程和網路協議通常採用這種方法。
協議工程編輯
計算機網路領域中最活躍的研究課題之一 ，目的是把軟體工程的原理和方法用於計算機網路協議的描述、實現和驗證工作 。協議工程的主要研究內容包括3 個方面：①協議形式化描述及其形式化描述語言。②協議軟體的自動生成技術及其開發維護工具。③協議一致性測試技術及其測試工具 。協議工程的研究有助於加深理解計算機網路協議，有助於提高協議軟體的生產效率，有助於改善網路協議軟體的維護管理水平。但是，協議工程與軟體工程相比，無論在研究、開發、應用的深度和廣度上說，均有距離，尚有廣闊的開拓、發展前景。
2. 計算機軟體系統的組成部分有哪些
軟體系統由系統軟體、支撐軟體和應用軟體組成，構成計算機系統的軟體部分。
操作系統負責管理計算機資源，調控程序運行。語言處理系統處理編程語言，如編譯程序等。資料庫系統支持數據管理和存取，包含資料庫、資料庫管理系統等。資料庫為計算機系統內駐留的數據集合，通過數據模式定義它們間的關系，以數據定義語言描述。資料庫管理系統允許用戶以抽象方式存取、利用和修改數據。
分布式軟體系統包括分布式操作系統、程序設計系統、文件系統、資料庫系統等，提供跨多個計算機網路的軟體服務。
人機交互系統是用戶與計算機系統信息交換的軟體，提供友好界面，實現約定的交互約定。
操作系統功能包括處理器管理、存儲管理、文件管理、設備管理和作業管理。主要研究內容涵蓋操作系統結構、進程調度、同步機制、死鎖預防、內存分配、設備分配、並行機制、容錯和恢復機制。
3. 怎麼避免死鎖
什麼是死鎖，如何避免死鎖？
線程A需要資源X，而線程B需要資源Y，而雙方都掌握有對方所要的資源，這種情況稱為死鎖（deadlock），或死亡擁抱（the deadly embrace）。
在並發程序設計中，死鎖 (deadlock) 是一種十分常見的邏輯錯誤。通過採用正確的編程方式，死鎖的發生不難避免。
死鎖的四個必要條件
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
在計算機專業的本科教材中，通常都會介紹死鎖的四個必要條件。這四個條件缺一不可，或者說只要破壞了其中任何一個條件，死鎖就不可能發生。我們來復習一下，這四個條件是：
互斥（Mutual exclusion）：存在這樣一種資源，它在某個時刻只能被分配給一個執行緒（也稱為線程）使用；
持有（Hold and wait）：當請求的資源已被佔用從而導致執行緒阻塞時，資源佔用者不但無需釋放該資源，而且還可以繼續請求更多資源；
不可剝奪（No preemption）：執行緒獲得到的互斥資源不可被強行剝奪，換句話說，只有資源佔用者自己才能釋放資源；
環形等待（Circular wait）：若干執行緒以不同的次序獲取互斥資源，從而形成環形等待的局面，想像在由多個執行緒組成的環形鏈中，每個執行緒都在等待下一個執行緒釋放它持有的資源。
解除死鎖的必要條件
不難看出，在死鎖的四個必要條件中，第二、三和四項條件比較容易消除。通過引入事務機制，往往可以消除第二、三兩項條件，方法是將所有上鎖操作均作為事務對待，一旦開始上鎖，即確保全部操作均可回退，同時通過鎖管理器檢測死鎖，並剝奪資源（回退事務）。這種做法有時會造成較大開銷，而且也需要對上鎖模式進行較多改動。
消除第四項條件是比較容易且代價較低的辦法。具體來說這種方法約定：上鎖的順序必須一致。具體來說，我們人為地給鎖指定一種類似「水位」的方向性屬性。無論已持有任何鎖，該執行緒所有的上鎖操作，必須按照一致的先後順序從低到高（或從高到低）進行，且在一個系統中，只允許使用一種先後次序。
請注意，放鎖的順序並不會導致死鎖。也就是說，盡管按照 鎖A, 鎖B, 放A, 放B 這樣的順序來進行鎖操作看上去有些怪異，但是只要大家都按先A後B的順序上鎖，便不會導致死鎖。
解決方法：
1 使用事務時，盡量縮短事務的邏輯處理過程，及早提交或回滾事務； (細化處理邏輯，執行一段邏輯後便回滾或者提交，然後再執行其它邏輯，直到事物執行完畢提交)
2 設置死鎖超時參數為合理范圍，如：3分鍾-10分種；超過時間，自動放棄本次操作，避免進程懸掛；
3 優化程序，檢查並避免死鎖現象出現；
4 .對所有的腳本和SP都要仔細測試，在正是版本之前。
5 所有的SP都要有錯誤處理（通過@error）
6 一般不要修改SQL SERVER事務的默認級別。不推薦強行加鎖
另外參考的解決方法：
按同一順序訪問對象
如果所有並發事務按同一順序訪問對象，則發生死鎖的可能性會降低。例如，如果兩個並發事務獲得 Supplier 表上的鎖，然後獲得 Part 表上的鎖，則在其中一個事務完成之前，另一個事務被阻塞在 Supplier 表上。第一個事務提交或回滾後，第二個事務繼續進行。不發生死鎖。將存儲過程用於所有的數據修改可以標准化訪問對象的順序。
避免事務中的用戶交互
避免編寫包含用戶交互的事務，因為運行沒有用戶交互的批處理的速度要遠遠快於用戶手動響應查詢的速度，例如答復應用程序請求參數的提示。例如，如果事務正在等待用戶輸入，而用戶去吃午餐了或者甚至回家過周末了，則用戶將此事務掛起使之不能完成。這樣將降低系統的吞吐量，因為事務持有的任何鎖只有在事務提交或回滾時才會釋放。即使不出現死鎖的情況，訪問同一資源的其它事務也會被阻塞，等待該事務完成。
保持事務簡短並在一個批處理中
在同一資料庫中並發執行多個需要長時間運行的事務時通常發生死鎖。事務運行時間越長，其持有排它鎖或更新鎖的時間也就越長，從而堵塞了其它活動並可能導致死鎖。保持事務在一個批處理中，可以最小化事務的網路通信往返量，減少完成事務可能的延遲並釋放鎖。
使用低隔離級別
確定事務是否能在更低的隔離級別上運行。執行提交讀允許事務讀取另一個事務已讀取（未修改）的數據，而不必等待第一個事務完成。使用較低的隔離級別（例如提交讀）而不使用較高的隔離級別（例如可串列讀）可以縮短持有共享鎖的時間，從而降低了鎖定爭奪。
使用綁定連接
使用綁定連接使同一應用程序所打開的兩個或多個連接可以相互合作。次級連接所獲得的任何鎖可以象由主連接獲得的鎖那樣持有，反之亦然，因此不會相互阻塞。
4. 計算機網路——TCP/UDP協議
計算機網路七層模型中，傳輸層有兩個重要的協議：
（1）用戶數據報協議UDP (User Datagram Protocol)
（2）傳輸控制協議TCP (Transmission Control Protocol)
UDP 在傳送數據之前不需要先建立連接。遠地主機的運輸層在收到UDP 報文後，不需要給出任何確認。雖然UDP 不提供可靠交付，但在某些情況下UDP 卻是一種最有效的工作方式。
TCP 則提供面向連接的服務。在傳送數據之前必須先建立連接，數據傳送結束後要釋放連接。TCP 不提供廣播或多播服務。由於TCP 要提供可靠的、面向連接的運輸服務，因此不可避免地增加了許多的開銷，如確認、流量控制、計時器以及連接管理等。
UDP 的主要特點是：
首部手段很簡單，只有8 個位元組，由四個欄位組成，每個欄位的長度都是兩個位元組。
前面已經講過，每條TCP 連接有兩個端點，TCP 連接的端點叫做套接字（socket）或插口。套接字格式如下：
套接寧socket= (IP 地址：埠號』）
每一條TCP 連接唯一地被通信兩端的兩個端點（即兩個套接宇）所確定。即：
TCP 連接＝ {socket1, socket2} = {(IP1: port1), (IP2: port2)}
3次握手鏈接
4次握手釋放鏈接
斷開連接請求可以由客戶端發出，也可以由伺服器端發出，在這里我們稱A端向B端請求斷開連接。
各個狀態節點解釋如下：
下面為了討論問題的萬便，我們僅考慮A發送數據而B 接收數據並發送確認。因此A 叫做發送方，而B 叫做接收方。
「停止等待」就是每發送完一個分組就停止發送，等待對方的確認。在收到確認後再發送下一個分組。
使用上述的確認和重傳機制，我們就可以在不可靠的傳輸網路上實現可靠的通信。像上述的這種可靠傳輸協議常稱為自動重傳請求ARQ (Automatic Repeat reQuest）。意思是重傳的請求是自動進行的。接收方不需要請求發送方重傳某個出錯的分組。
滑動窗口協議比較復雜，是TCP 協議的精髓所在。這里先給出連續ARQ 協議最基本的概念，但不涉提到許多細節問題。詳細的滑動窗口協議將在後面討論。
下圖表示發送方維持的發送窗口，它的意義是：位於發送窗口內的5 個分組都可連續發送出去，而不需要等待對方的確認。這樣，信道利用率就提高了。
連續ARQ 協議規定，發送方每收到一個確認，就把發送窗口向前滑動一個分組的位置。
接收方一般都是採用 累積確認 的方式。這就是說，接收方不必對收到的分組逐個發送確認，而是可以在收到幾個分組後，對按序到達的最後一個分組發送確認，這樣就表示：到這個分組為止的所有分組都己正確收到了。
累積確認 的優點是容易實現，即使確認丟失也不必重傳。但缺點是不能向發送方反映出接收方己經正確收到的所有分組的信息。
例如，如果發送方發送了前5 個分組，而中間的第3 個分組丟失了。這時接收方只能對前兩個分組發出確認。發送方無法知道後面三個分組的下落，而只好把後面的三個分組都再重傳一次。這就叫做Go-back-N （回退N ），表示需要再退回來重傳己發送過的N 個分組。可見當通信線路質量不好時，連續ARQ 協議會帶來負面的影響。
TCP 的滑動窗口是以位元組為單位的。現假定A 收到了B 發來的確認報文段，其中窗口是20 （位元組），而確認號是31 （這表明B 期望收到的下一個序號是31 ，而序號30 為止的數據己經收到了）。根據這兩個數據， A 就構造出自己的發送窗口，其位置如圖所示。
發送窗口表示：在沒有收到B 的確認的情況下， A可以連續把窗口內的數據都發送出去。凡是己經發送過的數據，在未收到確認之前都必須暫時保留，以便在超時重傳時使用。
發送窗口後沿的後面部分表示己發送且己收到了確認。這些數據顯然不需要再保留了。而發送窗口前沿的前面部分表示不允許發送的，因為接收方都沒有為這部分數據保留臨時存放的緩存空間。
現在假定A 發送了序號為31 ～ 41 的數據。這時發送窗口位置並未改變，但發送窗口內靠後面有11個位元組（灰色小方框表示）表示己發送但未收到確認。而發送窗口內靠前面的9 個位元組（ 42 ～ 50 ）是允許發送但尚未發送的。】
再看一下B 的接收窗口。B 的接收窗口大小是20，在接收窗口外面，到30 號為止的數據是已經發送過確認，並且己經交付給主機了。因此在B 可以不再保留這些數據。接收窗口內的序號（31～50）足允許接收的。B 收到了序號為32 和33 的數據，這些數據沒有按序到達，因為序號為31 的數據沒有收到（也許丟失了，也許滯留在網路中的某處）。 請注意， B 只能對按序收到的數據中的最高序號給出確認，因此B 發送的確認報文段中的確認號仍然是31 （即期望收到的序號）。
現在假定B 收到了序號為31 的數據，並把序號為31～33的數據交付給主機，然後B刪除這些數據。接著把接收窗口向前移動3個序號，同時給A 發送確認，其中窗口值仍為20，但確認號是34，這表明B 已經收到了到序號33 為止的數據。我們注意到，B還收到了序號為37, 38 和40 的數據，但這些都沒有按序到達，只能先存在接收窗口。A收到B的確認後，就可以把發送窗口向前滑動3個序號，指針P2 不動。可以看出，現在A 的可用窗口增大了，可發送的序號范圍是42～53。整個過程如下圖：
A 在繼續發送完序號42-53的數據後，指針P2向前移動和P3重合。發送窗口內的序號都已用完，但還沒有再收到確認。由於A 的發送窗口己滿，可用窗口己減小到0，因此必須停止發送。
上面已經講到， TCP 的發送方在規定的時間內沒有收到確認就要重傳已發送的報文段。這種重傳的概念是很簡單的，但重傳時間的選擇卻是TCP 最復雜的問題之一。
TCP採用了一種自適應演算法 ，它記錄一個報文段發出的時間，以及收到相應的確認的時間。這兩個時間之差就是報文段的往返時間RTT，TCP 保留了RTT的一個加權平均往返時間RTTs （這又稱為平滑的往返時間， S 表示Smoothed 。因為進行的是加權平均，因此得出的結果更加平滑）。每當第一次測量到RTT樣本時， RTTs值就取為所測量到的RTT樣本值。但以後每測量到一個新的RTT樣本，就按下式重新計算一次RTTs:
新的RTTs = (1 － α）×（舊的RTTs) ＋ α ×（新的RTT樣本）
α 越大表示新的RTTs受新的RTT樣本的影響越大。推薦的α 值為0.125，用這種方法得出的加權平均往返時間RTTs 就比測量出的RTT值更加平滑。
顯然，超時計時器設置的超時重傳時間RTO (RetransmissionTime-Out）應略大於上面得出的加權平均往返時間RTTs。RFC 2988 建議使用下式計算RTO:
RTO = RTTs + 4 × RTTd
RTTd是RTT 的偏差的加權平均值，它與RTTs和新的RTT樣本之差有關。計算公式如下：
新的RTTd= (1- β）×（舊的RTTd) + β × |RTTs－新的RTT樣本|
發現問題： 如圖所示，發送出一個報文段。設定的重傳時間到了，還沒有收到確認。於是重
傳報文段。經過了一段時間後，收到了確認報文段。現在的問題是：如何判定此確認報文段是對先發送的報文段的確認，還是對後來重傳的報文段的確認？
若收到的確認是對重傳報文段的確認，但卻被源主機當成是對原來的報文段的確認，則這樣計算出的RTTs 和超時重傳時間RTO 就會偏大。若後面再發送的報文段又是經過重傳後才收到確認報文段，則按此方法得出的超時重傳時間RTO 就越來越長。
若收到的確認是對原來的報文段的確認，但被當成是對重傳報文段的確認，則由此計算出的RTTs 和RTO 都會偏小。這就必然導致報文段過多地重傳。這樣就有可能使RTO 越來越短。
Kam 提出了一個演算法：在計算加權平均RTTs 時，只要報文段重傳了就不採用其往返時間樣本。這樣得出的加權平均RTTs 和RTO 就較准確。
新問題： 設想出現這樣的情況：報文段的時延突然增大了很多。因此在原來得出的重傳時間內，不會收到確認報文段。於是就重傳報文段。但根據Kam 演算法，不考慮重傳的報文段的往返時間樣本。這樣，超時重傳時間就無法更新。
解決方案： 對Kam 演算法進行修正，方法是z報文段每重傳一次，就把超時重傳時間RTO 增大一些。典型的做法是取新的重傳時間為2 倍的舊的重傳時間。當不再發生報文段的重傳時，才根據上面給出的公式計算超時重傳時間。
流量控制（flow control）就是讓發送方的發送速率不要太快，要讓接收方來得及接收。
利用滑動窗口機制可以很方便地在TCP 連接上實現對發送方的流量控制。
接收方的主機B 進行了三次流量控制。第一次把窗口減小到rwnd =300，第二次又減到rwnd = 100 ，最後減到rwnd = 0 ，即不允許發送方再發送數據了。這種使發送方暫停發送的狀態將持續到主機B 重新發出一個新的窗口值為止。我們還應注意到，B 向A 發送的三個報文段都設置了ACK=1，只有在ACK=1 時確認號欄位才有意義。
發生死鎖： 現在我們考慮一種情況。上圖中， B 向A 發送了零窗口的報文段後不久， B 的接收緩存又有了一些存儲空間。於是B 向A 發送了rwnd = 400 的報文段。然而這個報文段在傳送過程中丟失了。A 一直等待收到B 發送的非零窗口的通知，而B 也一直等待A 發送的數據。如果沒有其他措施，這種互相等待的死鎖局面將一直延續下去。
解決方案： TCP 為每一個連接設有一個 持續計時器（persistence timer） 。只要TCP 連接的一方收到對方的零窗口通知，就啟動持續計時器。若持續計時器設置的時間到期，就發送一個 零窗口探測報文段 （僅攜帶1 宇節的數據），而對方就在確認這個探測報文段時給出了現在的窗口值。
1 TCP連接時是三次握手，那麼兩次握手可行嗎？
在《計算機網路》中是這樣解釋的：已失效的連接請求報文段」的產生在這樣一種情況下：client發出的第一個連接請求報文段並沒有丟失，而是在某個網路結點長時間的滯留了，以致延誤到連接釋放以後的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段後，就誤認為是client再次發出的一個新的連接請求。於是就向client發出確認報文段，同意建立連接。假設不採用「三次握手」，那麼只要server發出確認，新的連接就建立了。由於現在client並沒有發出建立連接的請求，因此不會理睬server的確認，也不會向server發送ACK包。這樣就會白白浪費資源。而經過三次握手，客戶端和伺服器都有應有答，這樣可以確保TCP正確連接。
2 為什麼TCP連接是三次，揮手確是四次？
在TCP連接中，伺服器端的SYN和ACK向客戶端發送是一次性發送的，而在斷開連接的過程中，B端向A端發送的ACK和FIN是是分兩次發送的。因為在B端接收到A端的FIN後，B端可能還有數據要傳輸，所以先發送ACK，等B端處理完自己的事情後就可以發送FIN斷開連接了。
3 為什麼在第四次揮手後會有2個MSL的延時？
MSL是Maximum Segment Lifetime，最大報文段生存時間，2個MSL是報文段發送和接收的最長時間。假定網路不可靠，那麼第四次發送的ACK可能丟失，即B端無法收到這個ACK，如果B端收不到這個確認ACK，B端會定時向A端重復發送FIN，直到B端收到A的確認ACK。所以這個2MSL就是用來處理這個可能丟失的ACK的。
1 文件傳送協議
文件傳送協議FTP (File Transfer Protocol) [RFC 959］是網際網路上使用得最廣泛的文件傳送協議，底層採用TCP協議。
盯P 使用客戶伺服器方式。一個FTP 伺服器進程可同時為多個客戶進程提供服務。FTP的伺服器進程由兩大部分組成：一個主進程，負責接受新的請求：另外有若干個從屬進程，負責處理單個請求。
在進行文件傳輸時，客戶和伺服器之間要建立兩個並行的TCP 連接：「控制連接」（21埠）和「數據連接」（22埠）。控制連接在整個會話期間一直保持打開， FTP 客戶所發出的傳送請求，通過控制連接發送給伺服器端的控制進程，但控制連接並不用來傳送文件。實際用於傳輸文件的是「數據連接」。伺服器端的控制進程在接收到FTP 客戶發送來的文件傳輸請求後就創建「數據傳送進程」和「數據連接」，用來連接客戶端和伺服器端的數據傳送進程。
2 簡單文件傳送協議TFTP
TCP/IP 協議族中還有一個簡單文件傳送協議TFfP (Trivial File Transfer Protocol），它是一個很小且易於實現的文件傳送協議，埠號69。
TFfP 也使用客戶伺服器方式，但它使用UDP 數據報，因此TFfP 需要有自己的差錯改正措施。TFfP 只支持文件傳輸而不支持交耳。
3 TELNET
TELNET 是一個簡單的遠程終端協議，底層採用TCP協議。TELNET 也使用客戶伺服器方式。在本地系統運行TELNET 客戶進程，而在遠地主機則運行TELNET 伺服器進程，佔用埠23。
4 郵件傳輸協議
一個電子郵件系統應具如圖所示的三個主要組成構件，這就是用戶代理、郵件伺服器，以及郵件發送協議（如SMTP ）和郵件讀取協議（如POP3)， POP3 是郵局協議（Post Office Protocol）的版本3 。
SMTP 和POP3 （或IMAP ）都是在TCP 連接的上面傳送郵件，使用TCP 的目的是為了使郵件的傳送成為可靠的。
5. 常見網路故障與無線區域網問題詳解
常見網路故障與無線區域網問題詳解
因為互聯網的普及，在龐大用戶數量的背後，隨著而來的是各種人為的、非人為的網路故障。為什麼我能上QQ卻不能上網?為什麼淘寶又打不開了?為什麼訪問谷歌老是斷線?在種種疑問的背後，你是否曾經想過，到底是誰動了我的網路?下面由我帶來常見網路故障與無線區域網問題詳解。
一、網路故障
1、網卡正確安裝但重啟時報錯
這說明網卡根本沒有檢測到，或者在軟、硬體上配置有誤。可以從以下幾個方面來查：
1)、確保所用網卡被該操作系統支持。
2)、確保使用了正確的網卡驅動程序。
3)、用網卡所帶的設置程序正確設置其IRQ，I/O address，RAM address，網 線類型等。有跳線的要確保跳線正確。對於新的網卡，只要進入EISA 、PCI 設 置程序，使其設為自動檢測。
4)、用"hwconfig -hc" 可以檢測出配置中的沖突。在系統引導時也可以發現 類似"card not found" ，"unable to start"的錯誤。這說明軟體配置同硬體 有沖突。
5)、網卡配置後，重連內核，重啟。
6)、可以用ping 或 netstat 來檢查資源沖突。先ping 一區域網結點，再用："netstat -i"來看其收發包情況，如果Ipkts 增大，但Opkts 為 0，那麼I/O address 錯; 如果Opkts 增大，但Ipkts 為0， 則為IRQ 錯。
2、網卡正常檢測，但不能與其它電腦實現互連
這主要是由於網路掩碼或廣播地址配置錯、網線不通、網路協議不對、路由不對、網路 速度不匹配、網路程序包文件不完整等。
1)、首先用ping localhost、IP，若通，則說明本機TCP/IP工作正常;若不 通，則需重配重啟。再不行， 可用"fiWindows XPerm"來檢查網路程序包的完整性。重配 後請刪除"/etc/hosts"中多餘的記錄。
2)、用"ifconfig -a”檢查其它工作正常的區域網機器及其本身，應確保其網路掩碼及廣播地址一致(下劃線部分)。
例：#ifconfig -a
net0： flags=4043 mtu 1500 inet 164.230.
120.27 netmask ffff0000 broadcast 164.230.255.255 perf. params：
recv size： 24576; send size： 24576; full-size frames： 1
ether 00：80：5f：70：b2：f5
lo0： flags=4049mtu 8232 inet 127.0.0.1
netmask ff000000 perf. params： recv size： 57344; send size： 57344;
full-size frames： 1
如果網路掩碼及廣播地址與其它機器一樣，你可以用"arp -a" 發現其它機器的物理地址。若不能發現則可能因為是網線不通或網路掩碼及廣播地址配置不對。例：
# ping 164.230.1.10
Pinging 164.230.1.10 with 32 bytes of data：
Reply form 164.230.1.10 ： bytes=32 time=5ms TTL=255
Reply form 164.230.1.10 ： bytes=32 time=3ms TTL=255
.......
# arp -a
Internet Address Physical Address Type
164.230.1.10 00-06-29-ee-33-37 dynamic
3)、用"netstat -i"檢查Ipkts和 Opkts在ping前後的變化情況，如果二者均沒有增加，則說明網卡沒有包交換，需要更換可靠網線(其它工作正常機器上的)。
4)、有些網卡預設設置其速率為100M，也會導致網路不通，需要在根據所連HUB口的 速率，在其高級設置里設置其速率或設成AUTO。
3、電腦只能和部分機器互聯
這主要是針對網路間加了路由器的情形。由於不正常的路由、錯誤的子網分割或對方機器上設有相應的路由。或雙方的幀類型不同。可以從以下幾點來找出問題。
1)、用"traceroute 目的IP" 來找到包可到的機器A，問題往往出現在A的下一步B上，看看B上有無返回的路由。這樣一步一步到達目的IP。
2)、確保子網間的路由正確。
3)、確保同一區域網上機器使用同樣的幀類型。如：EthernetII ，802.3，802.5等。
4、網路間歇性地不通、減慢或死鎖
這主要是由於一些工作量大的程序，超出系統的負荷造成。這時需要調整內核參數。
1)、有時會出現類似"out of streams"等錯誤提示。先可以用"netstat -m" 來查看系統運行此程序所需的STREAMS。然後調整它。
2)、過時的驅動程序也會引起網路死鎖。這只要及時更新其最新版本即可。
5、網速很慢
這個問題有兩種可能，一是網路提供商的原因，另一種就是你機器本身的原因，網路提供商的問題我們這里就不講了，主要講一下機器本身的原因。
1)、網線問題
我們知道，雙絞線是由四對線按嚴格的`規定緊密地絞和在一起的，用來減少串擾和背景噪音的影響。同時，在T568A標准和T568B標准中僅使用了雙絞線的1、2和3、6四條線，其中，1、2用於發送，3、6用於接收，而且1、2必須來自一個繞對，3、6必須來自一個繞對。只有這樣，才能最大限度地避免串擾，保證數據傳輸。本人在實踐中發現不按正確標准(T586A、T586B)製作的網線，存在很大的隱患。表現為：一種情況是剛開始使用時網速就很慢;另一種情況則是開始網速正常，但過了一段時間後，網速變慢。後一種情況在台式電腦上表現非常明顯，但用筆記本電腦檢查時網速卻表現為正常。對於這一問題本人經多年實踐發現，因不按正確標准製作的網線引起的網速變慢還同時與網卡的質量有關。一般台式計算機的網卡的性能不如筆記本電腦的，因此，在用交換法排除故障時，使用筆記本電腦檢測網速正常並不能排除網線不按標准製作這一問題的存在。我們現在要求一律按T586A、T586B標准來壓制網線，在檢測故障時不能一律用筆記本電腦來代替台式電腦。
2)、網路中存在迴路
當網路涉及的節點數不是很多、結構不是很復雜時，這種現象一般很少發生。但在一些比較復雜的網路中，經常有多餘的備用線路，如無意間連上時會構成迴路。比如網線從網路中心接到計算機一室，再從計算機一室接到計算機二室。同時從網路中心又有一條備用線路直接連到計算機二室，若這幾條線同時接通，則構成迴路，數據包會不斷發送和校驗數據，從而影響整體網速。這種情況查找比較困難。為避免這種情況發生，要求我們在鋪設網線時一定養成良好的習慣：網線打上明顯的標簽，有備用線路的地方要做好記載。當懷疑有此類故障發生時，一般採用分區分段逐步排除的方法。
3)、網路設備硬體故障
作為發現未知設備的主要手段，廣播在網路中起著非常重要的作用。然而，隨著網路中計算機數量的增多，廣播包的數量會急劇增加。當廣播包的數量達到30%時，網路的傳輸效率將會明顯下降。當網卡或網路設備損壞後，會不停地發送廣播包，從而導致廣播風暴，使網路通信陷於癱瘓。因此，當網路設備硬體有故障時也會引起網速變慢。當懷疑有此類故障時，首先可採用置換法替換集線器或交換機來排除集線設備故障。如果這些設備沒有故障，關掉集線器或交換機的電源後，DOS下用“Ping”命令對所涉及計算機逐一測試，找到有故障網卡的計算機，更換新的網卡即可恢復網速正常。網卡、集線器以及交換機是最容易出現故障引起網速變慢的設備。
4)、某個埠形成了瓶頸
實際上，路由器廣域網埠和區域網埠、交換機埠、集線器埠和伺服器網卡等都可能成為網路瓶頸。當網速變慢時，我們可在網路使用高峰時段，利用網管軟體查看路由器、交換機、伺服器埠的數據流量;也可用Netstat命令統計各個埠的數據流量。據此確認網路數據流通瓶頸的位置，設法增加其帶寬。具體方法很多，如更換伺服器網卡為1查找計算機，找到其他組的計算機後作成快捷方式放在桌面上。