網(wǎng)絡編程你有沒有理解的透徹

進行程序開發(fā)的同學，無論Web前端開發(fā)、Web后端開發(fā)，還是搜索引擎和大數(shù)據(jù)，幾乎所有的開發(fā)領域都會涉及到網(wǎng)絡編程。比如我們進行Web服務端開發(fā)，除了Web協(xié)議本身依賴網(wǎng)絡外，通常還需要連接數(shù)據(jù)庫，而數(shù)據(jù)庫連接通常是通過網(wǎng)絡連接數(shù)據(jù)庫服務器，或者數(shù)據(jù)庫集群，如果負載太高還要搞個緩存集群。

我們在上學的時候基本學了網(wǎng)絡編程和網(wǎng)絡協(xié)議。但兩者之間的具體關系可能有些摸不到頭腦。這里我們首先重點介紹2個概念，一個概念是網(wǎng)絡編程，另外一個是協(xié)議。

我們知道網(wǎng)絡協(xié)議是一個分層的協(xié)議族，也就是是有一組協(xié)議構成，從下往上各自負責各自的功能。那什么是協(xié)議呢？協(xié)議的字面意思是共同計議，商議。簡單的理解其實就是多方進行溝通的規(guī)定。而網(wǎng)絡協(xié)議其實就是在網(wǎng)絡中多個計算節(jié)點進行交互、溝通的規(guī)定。如果根我們日常生活對比的話，協(xié)議可以理解為語言，比如漢語普通話。兩個人交流如果都用不通話，那么彼此都能理解對方表達的意圖。例如，一個人用四川話，而另外一個用浙江話，那溝通起來估計幾乎不太可能。網(wǎng)絡協(xié)議也是一樣的，通過對數(shù)據(jù)格式的規(guī)范化，從而使計算機之間能夠彼此明確對方的意圖。

下面本文介紹一下網(wǎng)絡編程，網(wǎng)絡編程也稱為socket編程，socket通常譯作“套接字”，但原意其實意譯應該為”接口“。也就是操作系統(tǒng)提供給開發(fā)人員進行網(wǎng)絡開發(fā)的API接口。這套接口通?？梢詤?shù)的調整支持多種協(xié)議，包括TCP、UDP和IP等等。下面本文從套接字編程和協(xié)議兩方面分別詳細的進行介紹。

網(wǎng)絡編程

為了便于理解，本文先從具體的內容開始，也就是通過一個實例介紹一下網(wǎng)絡編程是怎么回事。

本文將以TCP協(xié)議為例介紹網(wǎng)絡編程和協(xié)議之前的關系。為了簡單，便于理解，本文以Python為例進行介紹，如果不了解Python編程語言關系也不大，下面代碼很容易理解。我們知道在網(wǎng)絡通信中無論是BS架構還是CS架構，通常分為服務端和客戶端，只不過BS架構中的瀏覽器就是客戶端。因此，本文的示例也包含服務端和客戶端2部分的代碼。代碼功能很簡單，就是實現(xiàn)客戶端和服務端發(fā)送字符串。

客戶端服務端通信模型

這個代碼清單是服務端的代碼，這段代碼的作用就是在服務端的某個端口建立監(jiān)聽，并等待客戶端建立連接。完成連接建立后，等待客戶端發(fā)送數(shù)據(jù)，并將數(shù)據(jù)回傳給客戶端。

#！/usr/bin/env python3#-*- coding:utf-8 -*-from socket import *from time import cTImehost = ‘’port = 12345buffsize = 2048ADDR = （host，port）# 創(chuàng)建一個基于TCP協(xié)議的套接字tcTIme = socket（AF_INET，SOCK_STREAM）tcTIme.bind（ADDR）# 在指定的地址和端口監(jiān)聽tcTIme.listen（3）while True:print（‘Wait for connection 。..’） tctimeClient，addr = tctime.accept（）print（“Connection from ：”，addr） while True： data = tctimeClient.recv（buffsize）.decode（） if not data： breaktctimeClient.send（（‘［%s］ %s’ % （ctime（），data））.encode（））tctimeClient.close（）tctimeClient.close（）

閱讀服務端的代碼可以看出主要包括，socket、bind、listen、accept、recv和send幾個。其中值得關注的是listen和accept，兩者分別用于監(jiān)聽端口和接受客戶端的連接請求。

下面代碼清單是客戶端的實現(xiàn)，這里特別的地方是有一個connect函數(shù)，該函數(shù)實現(xiàn)與服務端建立連接。

#！/usr/bin/env python3#-*- coding:utf-8 -*-from socket import *HOST =‘localhost’PORT = 12345BUFFSIZE=2048ADDR = （HOST，PORT）tctimeClient = socket（AF_INET，SOCK_STREAM）tctimeClient.connect（ADDR）while True:data = input（“》”） if not data： breaktctimeClient.send（data.encode（）） data = tctimeClient.recv（BUFFSIZE）.decode（） if not data： breakprint（data）tctimeClient.close（）

通過上述示例代碼可以看出服務端通常是被動的，而客戶端則要主動一些。服務端程序建立對某個端口的監(jiān)聽，等待客戶端的連接請求?？蛻舳讼蚍斩税l(fā)送連接請求，不出意外的情況下連接建立成功，這時客戶端和服務端之前就可以互發(fā)數(shù)據(jù)了。當然，在實際生產環(huán)境中意外是經(jīng)常的，因此從協(xié)議和接口層面，需要處理各種意外，本文在協(xié)議部分將詳細介紹。

另外，本文實現(xiàn)了一個基本的客戶端和服務端通信的程序，這個模式的通信在實際生產中幾乎不再使用。在實際生產中為了提高數(shù)據(jù)傳輸和處理的效率，通常采用異步模式，這些內容超出了本文的介紹范圍，后續(xù)文章會逐漸介紹。

TCP協(xié)議詳解

前文說了網(wǎng)絡協(xié)議是網(wǎng)絡中不同計算機信息通信的語言，為了實現(xiàn)交互，這個語言就需要有一定的格式。本文以TCP協(xié)議為例進行介紹。

TCP協(xié)議是一個可靠的傳輸協(xié)議，其可靠性表現(xiàn)在2方面，一方面是保證數(shù)據(jù)包可以按照發(fā)送的順序到達，另外一方面是保證數(shù)據(jù)包一定程度的正確性（后文詳解為什么是一定程度上的正確性）。其可靠性的實現(xiàn)則基于2點技術，一點是具有一個CRC校驗，這樣如果數(shù)據(jù)包中的某些數(shù)據(jù)出現(xiàn)錯誤可以通過該校驗和發(fā)現(xiàn);另外一點是每個數(shù)據(jù)包都有一個序號，這樣就能保證數(shù)據(jù)包的順序性，如果出現(xiàn)錯位的數(shù)據(jù)包可以請求重發(fā)。

既然說到了格式，那我們先看一下TCP數(shù)據(jù)包的數(shù)據(jù)格式。如下圖是TCP數(shù)據(jù)包的格式，包括原端口、目的端口、序列號和標識位等等內容，內容有些多，看著可能有點眼花。但從大的方面理解，這個數(shù)據(jù)包其實只包含2部分內容，一個是包頭，另外一個則是具體需要傳輸?shù)臄?shù)據(jù)。在TCP協(xié)議的控制邏輯中，包頭起著最為關鍵的作用，它是TCP協(xié)議中諸如建立連接、斷開連接、重傳和錯誤校驗等各種特性的基礎。

包頭的其它信息的含義都比較明了，本文僅僅介紹幾個標志位（URG、ACK、PSH、RST、SYN和FIN）的含義。具體含義如下：

ACK： 確認序號有效。

RST：重置連接

SYN：發(fā)起一個新連接

FIN：釋放一個連接

連接的建立TCP在具體傳輸數(shù)據(jù)之前需要建立連接。這里的連接并不是物理連接，物理連接基于底層的協(xié)議已經(jīng)建立完成，而且TCP建立連接也是要假設底層連接已經(jīng)成功，TCP的連接其實是一個虛擬的，邏輯的連接。簡單粗暴的理解，就是客戶端和服務端分別記錄了各自接受到的數(shù)據(jù)包的序號，并且將自身設置為某種狀態(tài)。在TCP協(xié)議中，連接的建立通常成為3次握手，從字面的概念可以看出，連接的建立需要經(jīng)過3次確認的過程。

TCP協(xié)議3次握手的過程如圖所示，初始狀態(tài)客戶端和服務端都處于關閉狀態(tài)。主要過程分為3步：

客戶端發(fā)送預連接數(shù)據(jù)包： TCP的連接是由客戶端主動發(fā)起建立，客戶端會發(fā)送一個數(shù)據(jù)包（報文）給服務端，需要注意的是數(shù)據(jù)包中的SYN標識位為1。我們前文已經(jīng)介紹，如果SYN為1，則說明為建立連接的數(shù)據(jù)包。同時，在該數(shù)據(jù)包中包含一個請求序列號，該序列號也是建立連接的依據(jù)。

服務端回復連接確認： 服務端確認可以建立連接（服務端不一定可以建立連接，因為系統(tǒng)中套接字的數(shù)量是有限的）的情況下會向客戶端發(fā)送一個應答數(shù)據(jù)包。在應答數(shù)據(jù)包中會將ACK標志位設置為1，表示為服務端應答數(shù)據(jù)包。同時，在應答數(shù)據(jù)包中會設置請求序列號和應答序列號的值，具體參考圖3.

客戶端回復連接確認： 最后，客戶端再次發(fā)送一個連接確認數(shù)據(jù)包，告訴服務端連接建立成功。

從上面流程可以看出，連接的建立需要經(jīng)過多次交互，這就是我們日常中所說的建立連接是高成本的操作。在實際生產環(huán)境中，為了應對這個問題，會減少連接建立的頻度，通常的做法是建立連接池，傳輸數(shù)據(jù)時直接從連接池中獲取連接，而不是新建連接。

有人可能覺得可以對建立連接的過程進行優(yōu)化，比如將客戶端最后一次的確認取消掉，覺得這個沒有卵用。對于正常情況確實沒有多大的作用，這里主要是應對異常情況。因為網(wǎng)絡拓撲是非常復雜的，特別是在廣域網(wǎng)中，有著數(shù)不清的網(wǎng)絡節(jié)點，因此會出現(xiàn)各種異常情況。因此，TCP協(xié)議在設計的時候必須要保證異常情況下的可靠性。

我們這里舉一個例子，就是連接請求超時的情況。假設客戶端向服務端發(fā)送一個連接請求，由于各種原因，請求一直沒有到達服務端，因此服務端也就沒有回復連接確認消息?？蛻舳诉B接超時，因此客戶端重新發(fā)送一個連接請求到服務端，這次比較順利，很快到達了，并且順利建立了連接。之后，前一個數(shù)據(jù)包經(jīng)過長途跋涉最終還是到了服務端，服務端也向客戶端發(fā)送了回復數(shù)據(jù)包，服務端認為連接是建立成功的，并且會維持連接。但客戶端層面認為連接是超時的，因此將永遠不會關閉該連接。這樣就會造成服務端有殘留的資源，從而造成服務端資源浪費，久而久之可能會導致服務端無新連接資源可用。

另外一個需要說明的是客戶端和服務端的套接字都有相應的狀態(tài)，而且狀態(tài)會隨著連接的不同階段變化。初始狀態(tài)都是CLOSE，最終連接建立成功后都是ESTABLISHED，具體變化過程如圖3所示。后面本文會詳細介紹狀態(tài)變化情況。

傳輸數(shù)據(jù)完成連接建立之后，客戶端和服務端就可以進行數(shù)據(jù)傳輸了。我們知道TCP是可靠的傳輸，那么傳輸?shù)目煽啃允峭ㄟ^什么來保證的呢？主要就是通過包頭中的校驗和、請求序列號和應答序列號（參考圖2）。

TCP數(shù)據(jù)內容的可靠性是通過校驗和保證的。TCP在發(fā)送數(shù)據(jù)時都會計算整個數(shù)據(jù)包的校驗和，并存儲在包頭的校驗和字段中。接收方會按照規(guī)則進行計算，從而確認接收到的數(shù)據(jù)是否是正確的。發(fā)送發(fā)計算校驗和的流程大概如下：

把偽首部、TCP包頭和TCP數(shù)據(jù)分為16為的字，并把TCP包頭中的校驗和字段置0

用反碼加法累加所有16位數(shù)字

對計算結果去反，將其填充到TCP包頭的校驗和字段

接收方將所有原碼相加，高位疊加，如果全為1則表示數(shù)據(jù)正確，否則說明數(shù)據(jù)有錯誤。

TCP數(shù)據(jù)包順序的可靠性是通過請求序列號和應答序列號保證的。在數(shù)據(jù)傳輸中的每個請求都會有一個請求序列號，而在接收方接收到數(shù)據(jù)后會發(fā)送一個應答序列號，這樣發(fā)送方就能知道數(shù)據(jù)是否被正確接收，而接收方也能知道數(shù)據(jù)是否出現(xiàn)亂序，從而保證數(shù)據(jù)包的順序性。

斷開連接TCP關閉連接分為4步，稱為4次揮手。連接的關閉不一定是在客戶端發(fā)起，服務端也可以發(fā)起關閉連接。關閉連接的過程如下：

發(fā)起方發(fā)送一個FIN置位的數(shù)據(jù)包，用來請求關閉發(fā)送方到接收方的連接

接收方發(fā)送一個應答，ACK標志位為1，確認關閉。此時完成了發(fā)起方到接收方的連接，也即發(fā)送方無法再向接收方發(fā)送數(shù)據(jù)，但接收方還可以向發(fā)送方發(fā)送數(shù)據(jù)。

接收方數(shù)據(jù)傳輸完成后向發(fā)起方發(fā)送一個FIN為1的包，表示請求斷開連接

發(fā)起方回復一個ACK包，確認關閉成功

關閉連接流程示意圖

TCP是全雙工通信，因此關閉連接時需要雙向關閉連接。首先是關閉發(fā)起方關閉本端的連接，然后是關閉接收方在收到發(fā)起方的關閉請求后，除了回復關閉應答外，還要確保數(shù)據(jù)傳輸完成后發(fā)起一個關閉連接的請求，保證雙向同時關閉。

截止到這里，本文介紹了基于TCP協(xié)議進行網(wǎng)絡編程的主要內容。當然這個只是入門級的，如果需要真正理解TCP協(xié)議和網(wǎng)絡編程還需要學習很多內容。后續(xù)本號將陸續(xù)介紹給大家。