(转)计算机网络基础知识总结
原文：https://i.cnblogs.com/EditPosts.aspx?opt=1
? ? ? ? ??http://blog.csdn.net/scenlyf/article/details/52127296
? ? ? ? ?http://blog.csdn.net/shaozhenged/article/details/52047277
說到網絡相關知識，首先先說說計算機網絡體系結構中兩種最為重要的參考模型，OSI參考模型和TCP/IP參考模型。
1、OSI參考模型：
? ? ? ?OSI（Open System Interconnect），即開放式系統互聯。一般都稱為OSI參考模型，是ISO（國際標準化組織）組織在1985年研究的網絡互聯模型。該體系結構標準定義了網絡互連的七層框架（物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層和應用層），即ISO開放系統互連參考模型。第一層到第三層屬于OSI參考模型的低三層，負責創建網絡通信連接的鏈路；第四層到第七層為OSI參考模型的高四層，具體負責端到端的數據通信。在這一框架下進一步詳細規定了每一層的功能，以實現開放系統環境中的互連性、互操作性和應用的可移植性。?
OSI參考模型中，對等層協議之間交換的信息單元統稱為協議數據單元(PDU,Protocol Data Unit)。
傳輸層——數據段（Segment） 網絡層——分組（數據包）（Packet） 數據鏈路層——數據幀（Frame） 物理層——比特（Bit）
2、TCP/IP參考模型：
? ? ? ? TCP/IP參考模型是計算機網絡的祖父ARPANET和其后繼的因特網使用的參考模型。ARPANET是由美國國防部DoD（U.S.Department of Defense）贊助的研究網絡。逐漸地它通過租用的電話線連結了數百所大學和政府部門。當無線網絡和衛星出現以后，現有的協議在和它們相連的時候出現了問題，所以需要一種新的參考體系結構。這個體系結構在它的兩個主要協議出現以后，被稱為TCP/IP參考模型（TCP/IP reference model）。
? ? ? ?TCP/IP是一組協議的代名詞，它還包括許多協議，組成了TCP/IP協議簇。TCP/IP協議簇分為四層（從下到上分為第一、二、三、四層的），IP位于協議簇的第二層(對應OSI的第三層：網絡層)，TCP位于協議簇的第三層(對應OSI的第四層：傳輸層)。TCP/IP通訊協議采用了4層的層級結構，每一層都呼叫它的下一層所提供的網絡來完成自己的需求。這4層分別為：?
應用層：應用程序間溝通的層，如簡單電子郵件傳輸（SMTP）、文件傳輸協議（FTP）、網絡遠程訪問協議（Telnet）等。?
傳輸層：在此層中，它提供了節點間的數據傳送服務，如傳輸控制協議（TCP）、用戶數據報協議（UDP）等，TCP和UDP給數據包加入傳輸數據并把它傳輸到下一層中，這一層負責傳送數據，并且確定數據已被送達并接收。?
互連網絡層：負責提供基本的數據封包傳送功能，讓每一塊數據包都能夠到達目的主機（但不檢查是否被正確接收），如網際協議（IP）。?
網絡接口層：對實際的網絡媒體的管理，定義如何使用實際網絡（如Ethernet、Serial Line等）來傳送數據。
?
?
? ? ? ?
?
? ? ? ?OSI七層模型結構的協議體系結構結構完整，概念明確，但其只能算是理想的一種體系結構，在實際應用中顯得發雜，定義的層數越多，實現的難度也就隨之越大，所以TCP/IP的四層模型結構成了至今被大量運用的網絡體系的模型結構，但這并不意味著OSI就被擱置一旁甚至棄而不用。
3、兩種模型結構的比較：
共同點：
1）、OSI參考模型和TCP/IP參考模型都采用了層次結構的概念。
2）、都能夠提供面向連接和無連接兩種通信服務機制。
不同點：
1）、OSI采用的七層模型，而TCP/IP是四層結構。
2）、TCP/IP參考模型的網絡接口層實際上并沒有真正的定義，只是一些概念性的描述。而OSI參考模型不僅分了兩層，而且每一層的功能都很詳盡， ? ? ? ? ? ?甚至在數據鏈路層又分出一個介質訪問子層，專門解決局域網的共享介質問題。
3）、OSI模型是在協議開發前設計的，具有通用性。TCP/IP是先有協議集然后建立模型，不適用于非TCP/IP網絡。
4）、OSI參考模型與TCP/IP參考模型的傳輸層功能基本相似，都是負責為用戶提供真正的端對端的通信服務，也對高層屏蔽了底層網絡的實現細節。 ? ? ? ? ? ?所不同的是TCP/IP參考模型的傳輸層是建立在網絡互聯層基礎之上的，而網絡互聯層只提供無連接的網絡服務，所以面向連接的功能完全在TCP ? ? ? ? ?協議中實現，當然TCP/IP的傳輸層還提供無連接的服務，如UDP；相反OSI參考模型的傳輸層是建立在網絡層基礎之上的，網絡層既提供面向連 ? ? ? ? ?接的服務，又提供無連接的服務，但傳輸層只提供面向連接的服務。
5）、OSI參考模型的抽象能力高，適合與描述各種網絡；而TCP/IP是先有了協議，才制定TCP/IP模型的。
6）、OSI參考模型的概念劃分清晰，但過于復雜；而TCP/IP參考模型在服務、接口和協議的 區別上不清楚，功能描述和實現細節混在一起。
7）、TCP/IP參考模型的網絡接口層并不是真正的一層；OSI參考模型的缺點是層次過多，劃分意義不大但增加了復雜性。
8）、OSI參考模型雖然被看好，由于技術不成熟，實現困難；相反，TCP/IP參考模型雖然有許多不盡人意的地方，但還是比較成功的。
?
? ? ? ?關于TCP/IP的四層模型結構，也可以是五層結構，即在最底層加上了物理層，因為物理層注重的是信號的傳遞以及具有某些電機特性，所以嚴格的來講，應該將其加上，放在網絡接口層的下層位置。
?
?
4、關于各層間的作用(基于TCP/IP)：
1）、物理層：
? ? ? ??指的是電信號傳遞方式，比如現在以太網通用的網線(雙絞線)、早期以太網采用的同軸電纜(現在主要用于有線電視)、光纖等都屬于物理層的概念。 物理層的能力決定了最大傳輸速率、傳輸距離、抗干擾性等。集線器(Hub)是工作在物理層的網絡設備，用于雙絞線的連接和信號中繼(將已衰減的信號再次放大使之傳得更遠)。
?
2）、鏈路層：
? ? ??? 鏈路層有以太網、令牌環網等標準。鏈路層負責網卡設備的驅動、幀同步(就是說從網線上檢測到什么信號算作新幀的開始)、沖突檢測(如果檢測到沖突就自動重發)、 數據差錯校驗等工作。交換機是工作在鏈路層的網絡設備，可以在不同的鏈路層網絡之間轉發數據幀(比如十兆以太網和百兆以太網之間、以太網和令牌環網之間)，由于不同鏈路層的幀格式不同，交換機要將進來的數據包拆掉鏈路層首部重新封裝之后再轉發。
? ? ? ?網絡層的IP協議是構成Internet的基礎。Internet上的主機通過IP地址來標識，Internet上有大量路由器負責根據IP地址選擇合適的路徑轉發數據包，數據包從Internet上的源主機到目的主機往往要經過十多個路由器。路由器是工作在第三層的網絡設備，同時兼有交換機的功能，可以在不同的鏈路層接口之間轉發數據包。因此路由器需要將進來的數據包拆掉網絡層和鏈路層兩層首部并重新封裝。IP 協議不保證傳輸的可靠性,數據包在傳輸過程中可能丟失，可靠性可以在上層協議或應用程序中提供支持。
?
?
?
?
3）、網絡層：
?? ?? ??負責點到點的傳輸(這里的“點”指主機或路由器)，而傳輸層負責端到端 (end-to-end)的傳輸(這里的“端”指源主機和目的主機)。
? ? ? ?網絡層的主要作用就是路由和尋址，主要接觸到的是IP協議即為IP地址
? ? ? ?Layer3網絡層：對應設備有路由器
路由器的作用：
廣播、組播控制
對數據做尋址、選擇到達目的的網絡的最佳路徑
流量管理
連接廣域網（WAN）
IP地址概念的說明：
根據地址的概念，來舉例介紹網絡號和主機號的概念，以及路由尋址和路由的概念。
?
4）、傳輸層：
? ? ? ?該層定義了兩個重要的協議，即傳輸控制協議（TCP）或用戶數據報協議（UDP）。TCP是一種面向連接的、可靠的協議。就像打電話，雙方拿起電話互通身份之后就建立了連接，然后說話就行了，這邊說的話那邊保證聽得到，并且是按說話的順序聽到的，說完話掛機斷開連接。也就是說TCP傳輸的雙方需要首先建立連接，之后由TCP協議保證數據收發的可靠性,丟失的數據包自動重發，上層應用程序收到的總是可靠的數據流,通訊之后關閉連接。UDP協議不面向連接，也不保證可靠性，有點像寄信，寫好信放到郵筒里，既不能保證信件在郵遞過程中不會丟失，也不能保證信件是按順序寄到目的地的。使用UDP協議的應用程序需要自己完成丟包重發、消息排序等工作。
?
5）、應用層：
? ? ? ? ?為用戶提供各種所需的服務。比如：FTP，DNS，Telnet，SMTP等。
?
?
5、TCP/IP協議棧與數據封裝
? ? ? ?TCP/IP網絡協議棧分為應用層(Application)、傳輸層(Transport)、網絡層(Network)和鏈路層(Link)四層。
? ? ??關于兩臺計算機通過TCP/IP協議通訊的過程（局域網的兩個主機可以通信）見下圖：
? ? ??只有應用層由用戶提供，傳輸層及其以下的機制由內核提供。應用程序對通訊數據的含義進行解釋，而傳輸層及其以下的機制處理通訊的細節，將數據從一臺計算機通過一定的路徑發送到另一臺計算機。
? ? ? 應用層數據通過協議棧發到網絡上時，每層協議都要加上一個數據首部(header)，稱為封裝(Encapsulation)，如下圖所示:
?
?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?????TCP/IP數據包的封裝
過程：
? ? ? ?應用層將數據通過TCP/IP協議棧逐層向下傳遞，其下的每層接到來自上層的數據時，根據每層的協議都要在其數據的前端添加首部信息進行封裝。不同的協議層對數據包有不同的稱謂，在傳輸層叫做段(segment)，在網絡層叫做數據報(datagram),在鏈路層叫做幀(frame)。在經過鏈路層時，數據封裝成幀后發給物理層的傳輸介質上，到達目標主機后，每層協議再逐層剝掉其首部，最后遞交給目標主機應用層，進行應用程序處理，數據與源主機發送的數據一致。
? ??? ?每層都將數據包分為：有效頭部信息和有效載荷（數據）。對于有效數據稱之為“有效載荷”，添加的部分稱其為“報頭”。下層收到來自上層交付的數據時，對于下層來說并不關心其具體內容，因為站在當前層的角度來看，此時已添加上層報頭信息的數據整個都被視為有效載荷，當前層要做的只是繼續封裝該數據，即添加自己的報頭。而解包的過程亦是如此，每層只負責剝離自己能識別的報頭信息。任何數據報中的報頭信息必須包含"上層協議"，即要把當前的有效載荷交付給上層的誰。
?
?
上圖適應兩臺計算機在同一網段的情況，如果是不同網段，從源主機到目標主機間的數據傳輸則須經過一個或多個路由器，以實現數據的跨網絡傳輸。?
?
?
? ? ? ? 路由器是工作在第三層的網絡設備，同時兼有交換機的功能,可以在不同的鏈路層接口之間轉發數據包。因此路由器需要將進來的數據包拆掉網絡層和鏈路層兩層首部并重新封裝。在此過程中，仍認為在同一層進行了網絡連接。
? ? ? ?目的主機收到數據包后，如何經過各層協議棧最后到達應用程序呢？整個過程如下圖所示
1、以太網驅動程序根據以太網首部中的“上層協議”字段確定該數據幀的有效載荷(指除去協議首部之外實際傳輸的數據)是IP、ARP還是RARP協議的數據報。
2、交給相應的協議處理。假如是IP數據報，IP協議再根據IP首部中的“上層協議”字段確定該數據報的有效載荷是TCP、UDP、ICMP還是IGMP ，然后交給相應的協議處理。假如是TCP段或UDP段，TCP或UDP協議再根據TCP首部或UDP首部的“端口號”字段確定應該將應用層數據交給哪個用戶進程。
? ???IP 地址是標識網絡中特定主機的地址，而端口號就是同一臺主機上標識特定進程的地址，IP 地址和端口號合起來標識網絡中唯一的進程。
注意：
? ? ? ?雖然IP、ARP和RARP數據報都需要以太網驅動程序來封裝成幀，但是從功能上劃分，ARP和RARP屬于鏈路層，IP屬于網絡層。雖然ICMP、IGMP、TCP、UDP的數據都需要IP協議來封裝成數據報，但是從功能上劃分，ICMP、IGMP與IP同屬于網絡層，TCP和UDP屬于傳輸層。
?
?
6、以太網幀格式
?
其中的源地址和目的地址是指網卡的硬件地址(也叫MAC地址),長度是48位（12個字節）,是在網卡出廠時固化的。
?
幀協議類型字段有三種值，分別對應IP、ARP、RARP，而后是有效載荷的大小（數據長度）。幀末尾是CRC校驗碼，用于差錯校驗的。
幀協議其類型值分別為0800的IP協議，0806的ARP協議，0835的RARP協議。
用ifconfig命令看一下MAC地址，“HWaddr 00:1C:29:6E:00:8F”部分就是硬件地址。
。
? ? ?以太網幀中的數據長度規定最小46字節,最大1500字節，ARP和RARP數據包的長度不夠46字節，要在后面補填充位。
? ? ?最大值1500稱為以太網的最大傳輸單元(MTU)，不同的網絡類型有不同的MTU，如果一個數據包從以太網路由到撥號鏈路上，數據包長度大于撥號鏈路的MTU了，則需要對數據包進行分片(fragmentation)。ifconfig命令的輸出中也有“MTU:1500”。注意，MTU這個概念指數據幀中有效載荷的最大長度，不包括幀首部的長度。
?
7、ARP協議
?
????? ?概念：ARP協議原名為“地址解析協議”，是根據IP地址獲取物理地址的一個TCP/IP協議。主機發送信息時將包含目標IP地址的ARP請求廣播到網絡上的所有主機，并接收返回消息，以此確定目標的物理地址。收到返回消息后將該IP地址和物理地址存入本機ARP緩存中并保留一定時間，下次請求時直接查詢ARP緩存以節約資源。
? ?????目的：在網絡通訊時,源主機的應用程序知道目的主機的IP地址和端口號,卻不知道目的主機的硬件地址,而數據包首先是被網卡接收到再去處理上層協議的,如果接收到的數據包的硬件地址與本機不符,則直接丟棄。因此在通訊前必須獲得目的主機的硬件地址，ARP協議就起到這個作用。
? ? ???每臺主機都維護一個ARP緩存表,可以用arp -a命令查看。緩存表中的表項有過期時間(一般為20分鐘),如果20分鐘內沒有再次使用某個表項,則該表項失效,下次還要發ARP請求來獲得目的主機的硬件地址。
? ? ? 源MAC地址、目的MAC地址在以太網首部和ARP請求各出現一次,對于鏈路層為以太網的情況是多余的,但如果鏈路層是其它類型的網絡則有可能是必要的。幀協議類型字段有三種值，分別對應IP、ARP、RARP。硬件類型指鏈路層網絡類型,1為以太網。協議類型指要轉換的地址類型，0x0800為IP地址。后面兩個地址長度對于以太網地址和IP地址分別為6和4(字節)，即0604。op字段：op字段為1表示ARP請求,op字段為2表示ARP應答。??
例如：A主機（源地址）向B主機（目的地址）進行ARP請求，A的MAC為：00:05:5d:61:58:a8；A的IP地址：c0?a8 00 37(192.168.0.55)。
? ? ? ? ? B的MAC為：00:05:5d:a1:b8:40；B的IP地址：c0?a8 00 02(192.168.0.2).
請求幀為?
以太網首部(14字節)?ff ff ff ff ff?00 05 5d 61 58 a8?08 06?? ? ? ? //廣播地址的目標地址是全1。08 06：ARP幀
APR幀(28字節) ? ??
00 01 ? ? ? ? ? ? ? ? ? ? ? ? ?//硬件類型表示為以太網；硬件地址(MAC地址)長度為6,協議地址(IP地址)長度為4（0604）
08 0006 04?00 01?00 05 5d 61 58 a8?c0 a8 00 37????//協議類型0800表示為IP地址；op為0x0001表示請求；
00 00 00 00 00 00c0 ?a8 00 02? ?//此處目的以太網地址為全0，IP地址為B的。A主機ARP的目的就是獲得B主機硬件地址（MAC地址/物理地址）。
填充位（18字節）
應答幀為：
以太網首部 （字節）?00 05 5d 61 58 a8?00 05 5d a1 b8 40?08 06
?
APR幀(28字節) ? ??
?
00 01 ? ? ? ? ? ? ? ? ? ? ?
08 00?06 04?00 02?00 05 5d a1 b8 40?c0 a8?00 02???//op為0x0002表示應答；
00 05 5d 61 58 a8?c0 ?a8 00 37??//目的以太網地址和IP地址為A的
填充位（18字節）
8、RARP協議
RARP協議
? ? ? ?原名為“反向地址解析協議”，允許局域網的物理機器從網關服務器的ARP表或者緩存上請求其IP地址。網絡管理員在局域網網關路由器里創建一個表以映射物理地址（MAC）和與其對應的IP地址。當設置一臺新的機器時，其RARP客戶機程序需要向路由器上的 RARP 服務器請求相應的IP地址。假設在路由表中已經設置了一個記錄，RARP 服務器將會返回 IP 地址給機器，此機器就會存儲起來以便日后使用。
產生原因
? ? ?ARP（地址解析協議）是設備通過自己知道的IP地址來獲得自己不知道的物理地址的協議。假如一個設備不知道它自己的IP地址，但是知道自己的物理地址，設備知道的只是網絡接口卡上的物理地址時，又該怎么辦呢？?為解決這種情況，就有了與ARP對應的RARP協議。
工作方式
? ? ??RARP以與ARP相反的方式工作。RARP發出要反向解析的物理地址并希望返回其對應的IP地址，應答包括由能夠提供所需信息的RARP服務器發出的IP地址。雖然發送方發出的是廣播信息，RARP規定只有RARP服務器能產生應答。許多網絡指定多個RARP服務器，這樣做既是為了平衡負載也是為了作為出現問題時的備份。
?
9、IP協議（重點）
? ? ? ?IP數據報的格式，見下圖：
? ? ? ?IP數據報的首部長度和數據長度都是可變長的,但總是4字節的整數倍。對于IPv4 ,4位版本字段是4。4位首部長度的數值是以4字節為單位的,最小值為5,也就是首部長度最小是4x5=20字節, 也就是不帶任何選項的IP首部,4位能表示的最大值是15,也就是首部長度最大是60字節。8位TOS字段有3個位用來指定IP數據報的優先級(目前已經廢棄不用),還有4個位表示可選的服務類型(最小延遲、最大呑吐量、最大可靠性、最小成本),還有一個位總是0。?
? ? ? ?16位總長度是整個數據報(包括IP首部和IP層payload)的字節數。16位標識：每傳一個IP數據報,16位的標識加1,可用于分片和重新組裝數據報。
? ? ? ?3位標志和13位片偏移用于分片。
? ? ? ?TTL(Time to live)是這樣用的:源主機為數據包設定一個生存時間,比如64,每過一個路由器就把該值減1,如果減到0就表示路由已經太長了仍然找不到目的主機的網絡,就丟棄該包,因此這個生存時間的單位不是秒,而是跳(hop)。協議字段指示上層協議是TCP、UDP、ICMP還是IGMP。然后是校驗和,只校驗IP首部,數據的校驗由更高層協議負責。IPv4的IP地址長度為32位。
下面主要進行說明IP分片和重組
3個標志位：
?
1）、最高位必須為0，該位必須復制到所有分組中。
2）、不分片位（no not fragment，DF位）。DF=0表示可以分片；DF=1表示接受主機對分組不能分片。如果長度超過MTU(最大傳輸單元)而又不可以分片的話，那么只能丟棄該組，并且用ICMP差錯報文向源主機報告。
3）、分片位（More fragment,MF位）。該位表示是否是最后一個分片，MF=1表示接收的分組不是最后一片，否則表示是最后一片。
IP如何分片：
1）、檢查DF標志位，檢查是否允許分片。如果設置了該位，則數據報將被丟棄，并將一個ICMP錯誤返回給源主機。
2）、基于MTU，確定片長度，將數據長度分為若干部分。（除了最后的數據部分，所有新建的數據選項的長度必須是8個字節的整數倍。）
3）、每個數據部分被放入一個IP數據報，這些數的數據報的報頭略微修改了原來的報文頭。
4）、除了最后的數據報分片外，每個分片都設置了多個分片標志位。
5）、每個分片的偏移量字段設置為這個數據部分在原來的數據報所占的位置，這個位置相當于原來未分片的數據報的開頭處。
6）、如果在原來的數據報中包括了選項，則選項類型字節的高位字節決定了這個信息是被復制到所有的分片數據段，還是只復制到了第一個數據報。
7）、設置新數據報的報文頭字段及總長度字段。
8）、重新計算報文頭部校驗和。
IP的組裝：
? ? ? ? 為了高效第組裝分片，用于保存分片的數據結構必須做到：
1）、快速定位屬于某一數據報的一組分組。
2）、在屬于某一數據報的一組分片中快速插入新的分片。
3）、有效地判斷一個數據報的所有分片是否已經全部接收。
4）、具有組裝超時機制，如果在重組完成之前定時器溢出，則刪除該數據報的所有內容。
?
?
關于IP協議常見的問題：
1、為什么IP不是可靠連接的協議
? ? ?IP層沒有超時和重傳機制，沒有連接握手協議。
2、IP數據報經過路由器都做了哪些改動
? ? ?IP沒經過一個路由器，TTL數就會減一，如果最后TTL為0了，但是依然沒有到達目的地，這個IP包將會被丟棄。這樣做了目的是為了防止出現循環回路。并且最后一跳的路由器會發送一個ICMP不可達的數據包給源IP。
3、關于分片的問題
? ? ? IP數據包的長度為16，也就是說最大為65535個字節。但是我們知道數據鏈路層規定MTU最大傳輸單元為1500個字節。當IP數據包的大小超過了1500，IP數據包必須要進行分片處理。這還只是初始發送端的分片，在網絡中如果某個路由器的MTU小于1500，那么還需要在路由器端做分片，這就給IP包的完整接收照成了很大的不確定性（我們知道數據包達到終點不一定是按照順序的），因為萬一某一個分片丟失，可能會造成真個IP重傳，當然前提是高層協議支持重傳。對于TCP協議，不存在分片的問題，因為TCP報頭的選項字段有MSS字段，規定一個TCP包最大可傳輸的字節數，一般是1500-20-20=1460字節。也就是說到達IP封包的時候最大可承載數據只有1460個字節，這樣就可以避免分片的問題。但是對于UDP這一類的協議，分片操作還是交給IP完成，雖然這樣可以增加載荷的效率，但是穩定性會受到很大的影響。
?
?
IP地址與路由：
IP地址分為5類：（IPv4的IP地址長度為4字節,通常采用點分?十進制表示法）
A類 0.0.0.0到127.255.255.255?
B類 128.0.0.0到191.255.255.255
C類 192.0.0.0到223.255.255.255
D類 224.0.0.0到239.255.255.255?
E類 240.0.0.0到247.255.255.255
? ? ? ?IP地址與子網掩碼做與運算可以得到網絡號,主機號從全0到全1就是子網的地址范圍。
? ? ? ?127.*的IP地址用于本機環回(loop back)測試,通常是127.0.0.1。loopback是系統中一種特殊的網絡設備,如果發送數據包的目的地址是環回地址或者與本機其它網絡設備的IP地址相同，則數據包不會發送到網絡介質上,而是通過環回設備再發回給上層協議和應用程序,主要用于測試。
一些不能用作主機IP 地址的特殊地址:
? ? ? 目的地址為255.255.255.255 ,表示本網絡內部廣播,路由器不轉發這樣的廣播數據包。
? ? ? 主機號全為0的地址只表示網絡而不能表示某個主機,如192.168.10.0(假設子網掩碼 為255.255.255.0)。
? ? ? 目的地址的主機號為全1,表示廣播至某個網絡的所有主機,例如目的地址192.168.10.255表示廣播至192.168.10.0網絡(假設子網掩碼為255.255.255.0)。
? ? ? ? 路由表：由很多路由條目組成,每個條目都指明去往某個網絡的數據包應該經由哪個接口發送,其中最后一條是缺省路由條目。路由條目路由表中的一行,每個條目主要由目的網絡地址、子網掩碼、下一跳地址、發送接口四部分組成,如果要發送的數據包的目的網絡地址匹配路由表中的某一行,就按規定的接口發送到下一跳地址。缺省路由條目路由表中的最后一行,主要由下一跳地址和發送接口兩部分組成,當目的地址與路由表中其它行都不匹配時,就按缺省路由條目規定的接口發送到下一跳地址。
? ? ? ? 路由是從尋找目標網絡開始的，對于路由來說其找尋目標網絡地址一般有三種可能：
? ? ? ? 1、知道，但當前網段找不到（送至下一路由）；2、不知道，也找不到。（送至默認網關）；3、知道，也能在當前網段找到。
? ? ???路由如何確定要發送的網絡號？
? ? ? ?IP數據報中存有目標IP地址，所以當路由獲得該地址時，通過與子網掩碼的“與”操作，便能得到一個網絡號，將其與路由表中的目標地址（Destination）條目進行逐一比對，如果比對成功則通過該網絡號對應的發送接口（Use?Iface）發出；若未匹配到，則說明不在該局域網絡，須將其從eth0的發送接口發出，將其送至默認網關處，再由其路由表決定下一跳的地址。
?
10、UDP協議
?
?
? ? ? ?UDP協議全稱是用戶數據報協議，在網絡中它與TCP協議一樣用于處理數據包，是一種無連接的協議。在OSI模型中，在第四層的傳輸層，處于IP協議的上一層。UDP有不提供數據包分組、組裝和不能對數據包進行排序的缺點，也就是說，當報文發送之后，是無法得知其是否安全完整到達的。UDP用來支持那些需要在計算機之間傳輸數據的網絡應用。包括網絡視頻會議系統在內的眾多的客戶/服務器模式的網絡應用都需要使用UDP協議。UDP協議從問世至今已經被使用了很多年，雖然其最初的光彩已經被一些類似協議所掩蓋，但是即使是在今天UDP仍然不失為一項非常實用和可行的網絡傳輸層協議。
?
? ? ??UDP協議不面向連接,也不保證傳輸的可靠性。例如:發送端的UDP協議層只管把應用層傳來的數據封裝成段交給IP協議層就算完成任務了,如果因為網絡故障該段無法發到對方,UDP協議層也不會給應用層返回任何錯誤信息。接收端的UDP協議層只管把收到的數據根據端口號交給相應的應用程序就算完成任務了,如果發送端發來多個數據包并且在網絡上經過不同的路由,到達接收端時順序已經錯亂了,UDP協議層也不保證按發送時的順序交給應用層。通常接收端的UDP協議層將收到的數據放在一個固定大小的緩沖區中等待應用程序來提取和處理,如果應用程序提取和處理的速度很慢,而發送端發送的速度很快,就會丟失數據包,UDP協議層并不報告這種錯誤。因此,使用UDP協議的應用程序必須考慮到這些可能的問題并實現適當的解決方案,例如等待應答、超時重發、為數據包編號、流量控制等。一般使用
UDP協議的應用程序實現都比較簡單,只是發送一些對可靠性要求不高的消息,而不發送大量的數據。例如,基于UDP的TFTP協議一般只用 trivial ftp TCP FTP于傳送小文件,而基于TCP的協議適用于各種文件的傳輸。
UDP協議的特點：UDP使用底層的互聯網協議來傳送報文，同IP一樣提供不可靠的無連接數據包傳輸服務。它不提供報文到達確認、排序、及流量控制等功能。
?
11、TCP協議（重點）
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?TCP段格式
?
? ? ?? 這里主要說一下六個標志位，URG、ACK、PSH、RST、SYN和FIN。
? ? ?? SYN表示建立連接，FIN表示關閉連接；ACK表示響應；PSH表示有 DATA數據傳輸；RST表示連接重置；URG表示緊急指針字段有效。
? ? ? ?SYN、FIN、ACK位：其中ACK是可能與SYN，FIN等同時使用的，比如SYN和ACK可能同時為1，它表示的就是建立連接之后的響應。如果只是單個的一個SYN，它表示的只是建立連接。TCP的幾次握手就是通過這樣的ACK表現出來的。但SYN與FIN是不會同時為1的，因為前者表示的是建立連接，而后者表示的是斷開連接。
? ? ? ??RST位：RST一般是在FIN之后才會出現為1的情況，表示的是連接重置。一般地，當出現FIN包或RST包時，我們便認為客戶端與服務器端斷開了連接；而當出現SYN和SYN＋ACK包時，我們認為客戶端與服務器建立了一個連接。
? ? ? ??PSH位（Push）：PSH為1的情況，一般只出現在 DATA內容不為0的包中，也就是說PSH為1表示的是有真正的TCP數據包內容被傳遞。TCP的連接建立和連接關閉，都是通過請求－響應的模式完成的。當兩個應用進程進行交互式的通信中，有時在一端的應用程序希望在鍵入一個命令后立即收到對應的響應。在這種情況下，TCP就可以使用推送操作。通常的數據中都會帶有PSH，但URG只在緊急數據才設置，也稱“帶外數據”。
? ? ? ?URG位（URGent）：當URG=1時，表示緊急指針字段有效。他告訴系統次報文段有緊急指針，應該盡快的處理（相當于高優先級的數據），而不要按照原來的排序序列來傳送。若不使用緊急指針，那么這兩個字符將存儲在接收TCP的緩存末尾。只有在所有數據段被處理完畢后這兩個字符才能被交付到接收方的網應用進程。URG是一個正偏移，與TCP首部中序號字段的值相加表示緊急數據后面的字節，即緊急指針是指向緊急數據最后一個字節的下一字節。
?
TCP協議
?1）、應用層向TCP層發送用于網間傳輸的、用8位字節表示的數據流，然后TCP把數據流分區成適當長度的報文段（通常受該計算機連接的網絡的數據鏈路層的最大傳輸單元（MTU）的限制）。
?2）、TCP把結果包傳給IP層，由它來通過網絡將包傳送給接收端實體的TCP層。TCP為了保證不發生丟包，就給每個包一個序號，同時序號也保證了傳送到接收端實體的包的按序接收。
?3）、接收端實體對已成功收到的包發回一個相應的確認（ACK）。如果發送端實體在合理的往返時延（RTT）內未收到確認，那么對應的數據包就被假設為已丟失將會被進行重傳。TCP用一個校驗和函數來檢驗數據是否有錯誤，在發送和接收時都要計算校驗和。
? ? ? ?TCP（Transmission Control Protocol 傳輸控制協議）是一種面向連接的、可靠的、基于字節流的傳輸層通信協議，由IETF的RFC793定義。在簡化的計算機網絡OSI模型中，它完成第四層傳輸層所指定的功能，用戶數據報協議（UDP）是同一層內另一個重要的傳輸協議。在因特網協議族（Internet protocol suite）中，TCP層是位于IP層之上，應用層之下的中間層。不同主機的應用層之間經常需要可靠的、像管道一樣的連接，但是IP層不提供這樣的流機制，而是提供不可靠的包交換。
提起TCP，就不得不提及TCP的三次握手和四次揮手，其過程見下圖用例：
?
?
? ? ?
三次握手可概括為：請求連接，收到應答，再次請求。 ? ? ? ? ? ? ? ? ? ?SYN ----> SYN --------> ?ACK
? ? ? 四次揮手可概括為：主動請求釋放，主端收到應答，對端請求釋放，對端收到應答。 ? ?FIN--------->ACK-------->FIN--------->ACK
?
為何要三次握手呢？兩次可以嗎？
? ? ? ? 三次握手完后的數據傳輸也是基于請求應答模式的，從而很好的解決了丟包問題。
1）TCP的三次握手最主要是防止已過期的連接再次傳到被連接的主機。如果采用兩次的話，會出現下面這種情況。
? ? ?比如是A機要連到B機，結果發送的連接信息由于某種原因沒有到達B機；于是，A機又發了一次，結果這次B收到了，于是就發信息回來，兩機就連接。傳完東西后，斷開。結果這時候，原先沒有到達的連接信息突然又傳到了B機，于是B機發信息給A，然后B機就以為和A連上了，這個時候B機就在等待A傳東西過去。
2）三次握手改成僅需要兩次握手，死鎖是可能發生
? ? ? ?考慮計算機A和B之間的通信，假定B給A發送一個連接請求分組，A收到了這個分組，并發送了確認應答分組。按照兩次握手的協定，A認為連接已經成功地建立了，可以開始發送數據分組。可是，B在A的應答分組在傳輸中被丟失的情況下，將不知道A是否已準備好，不知道A建議什么樣的序列號，B甚至懷疑A是否收到自己的連接請求分組。在這種情況下，B認為連接還未建立成功，將忽略A發來的任何數據分組，只等待連接確認應答分組。而A在發出的分組超時后，重復發送同樣的分組，資源會大大浪費。這樣就形成了死鎖。
?
為何要四次揮手呢？
? ? ? ?四次揮手：連接釋放，確保數據能夠完成傳輸。在創建連接時，發送端和接收端分別建立連接并以相應的數據結構進行建立維護，在一定程度上兩端處于一個對等的關系。當一放釋放連接時，并不能保證對端數據是否發送完畢，所以需要進行釋放連接的請求，等待對端確認，所以一來一回，共四次。TCP協議是面向字節流的，是一種流式服務，全雙工的。本端發送和接受數據兩不誤。?
? ? ? ??揮手需要雙發都同意才能結束。即關閉連接時，當收到對方的FIN報文通知時，它僅僅表示對方沒有數據發送給你了；但未必你所有的數據都全部發送給對方了，所以你可以未必會馬上會關閉SOCKET,也即你可能還需要發送一些數據給對方之后，再發送FIN報文給對方來表示你同意現在可以關閉連接了，所以它這里的ACK報文和FIN報文多數情況下都是分開發送的。
?
?原文：http://whoshell.com/2017/06/18/%E7%BD%91%E7%BB%9C%E5%9F%BA%E7%A1%80%E5%AD%A6%E4%B9%A0%E6%80%BB%E7%BB%93-1/#more
網絡基礎學習總結(1)
做web開發呢，除了前端后端技術要熟練使用外，想要更進一步學習web原理，那必須還得了解計算機網絡的一些基礎知識。計算機網絡范圍其實很廣，內容雜多。說來慚愧啊，上學時候，上課都沒有認真思考，實驗也沒有充分發揮主觀能動性，浪費了現有硬件資源來對網絡進行更深的學習。但是，在日常工作中，對這些原理的東西也不能一概不知。就打算來說說，網絡中的一些基礎內容，包括：數據傳輸模型OSI,TCP/IP，TCP協議的建立與釋放，IP數據報的傳輸與數據格式等等。
網絡通信模型
因為從計算機整個發展到現在的歷程來看，從沒有操作系統的單太計算機，只是用于數據簡單處理的計算機，到后來的批處理系統，多道程序系統，到分時系統，實時系統的發展，計算機處理能力呈現爆炸性增長，伴隨著處理能力提升，早起不同的計算機公司開發自己定義的計算機系統以及計算機通信協議，導致了不同的公司或者說不同的硬件底層支持的計算機的通信會很復雜，硬件的異構型造成了計算機通信的成本花費很大。特別是萬維網的創建，更是將整個實驗室，縣城，市區到國家之間的計算機通信互聯的現實需求推至頂端。
那么為了不同公司，不同類型的計算機進行通信更高效，方便，那么無規矩不成方圓。權威機構當然就聯合起來，共同定制合理有效的計算機通信模型以及協議等等。也是適應時代發展的需要和推動計算機互聯網的快速發展的必然結果。
OSI參考模型
該模型定義了不同計算機互聯的標準，是設計和描述計算機網絡通信的基本框架。開放系統互聯參考模型的系統結構共分7層。在該模型中層與層之間進行對等通信，且這種通信只是邏輯上的，真正的通信都是在最底層-物理層實現的，每一層要完成相應的功能，下一層為上一層提供服務，從而把復雜的通信過程分成了多個獨立的、比較容易解決的子問題。–引用自百度OSI
下面這張圖，把整個OSI協議模型以及每層協議棧上的一些協議給列出來了：（圖片來源自網絡）
該OSI通信框架知道有7層，那七層，每層大致做得什么，有什么作用就夠了。在此就不細說了。
TCP/IP參考模型
TCP/IP參考模型是計算機網絡的祖父ARPANET和其后繼的因特網使用的參考模型。ARPANET是由美國國防部DoD（U.S.Department of Defense）贊助的研究網絡。逐漸地它通過租用的電話線連結了數百所大學和政府部門。當無線網絡和衛星出現以后，現有的協議在和它們相連的時候出現了問題，所以需要一種新的參考體系結構。這個體系結構在它的兩個主要協議出現以后，被稱為TCP/IP參考模型（TCP/IP reference model）。–引用自百度TCP/IP參考模型
這個TCP/IP參考模型有四層：網絡訪問層、網際互聯層、傳輸層（主機到主機）、和應用層。(圖片引用自網絡)
兩種模型的比較
共同點
（1）OSI參考模型和TCP/IP參考模型都采用了層次結構的概念。
（2）都能夠提供面向連接和無連接兩種通信服務機制。
不同點
（1）OSI采用的七層模型，而TCP/IP是四層結構。
（2）TCP/IP參考模型的網絡接口層實際上并沒有真正的定義，只是一些概念性的描述。而OSI參考模型不僅分了兩層，而且每一層的功能都很詳盡，甚至在數據鏈路層又分出一個介質訪問子層，專門解決局域網的共享介質問題。
（3）OSI模型是在協議開發前設計的，具有通用性。TCP/IP是先有協議集然后建立模型，不適用于非TCP/IP網絡。
（4）OSI參考模型與TCP/IP參考模型的傳輸層功能基本相似，都是負責為用戶提供真正的端對端的通信服務，也對高層屏蔽了底層網絡的實現細節。所不同的是TCP/IP參考模型的傳輸層是建立在網絡互聯層基礎之上的，而網絡互聯層只提供無連接的網絡服務，所以面向連接的功能完全在TCP協議中實現，當然TCP/IP的傳輸層還提供無連接的服務，如UDP；相反OSI參考模型的傳輸層是建立在網絡層基礎之上的，網絡層既提供面向連接的服務，又提供無連接的服務，但傳輸層只提供面向連接的服務。
（5）OSI參考模型的抽象能力高，適合與描述各種網絡；而TCP/IP是先有了協議，才制定TCP/IP模型的。
（6）OSI參考模型的概念劃分清晰，但過于復雜；而TCP/IP參考模型在服務、接口和協議的 區別上不清楚，功能描述和實現細節混在一起。
（7）TCP/IP參考模型的網絡接口層并不是真正的一層；OSI參考模型的缺點是層次過多，劃分意義不大但增加了復雜性。
（8）OSI參考模型雖然被看好，由于沒把握好時機，技術不成熟，實現困難；相反，TCP/IP參考模型雖然有許多不盡人意的地方，但還是比較成功的。
– 引用自百度
數據通信
在了解了現代計算機之間的數據通信模型后，就可以來具體看看計算機之間是如何進行數據傳遞的，在傳遞過程中會遇到什么問題，數據是以什么樣的形式進行封裝傳輸的。若是在傳輸中出現錯誤，又是如何進行處理的。其實，有很多問題值得我們思考并進行更深層次的理解與代碼開發。
因為數據的傳輸大致就是兩種：WLAN廣域網內的計算機互聯通信以及LAN局域網內的主機進行互聯通信。所以其實數據的產生和傳輸都是需要硬件支持的，若是能了解一些常見的計算機網絡硬件如：網絡交換機，路由器，集線器等，還有以太網技術和VLAN虛擬局域網，可能會更能加深對整個數據通信過程的理解把。有些硬件中對協議通信的支持能力很高，智能的接收數據，轉發數據等等，有些則是常規的數據轉發推送等。
數據封裝解封流程
因為，從上面模型可以知道。數據的傳輸過程中，需要經過不同層次的協議棧，那么每個層次對傳輸的數據是如何處理的呢？[以以太網網絡為背景]
其實，在實際數據的通信傳輸過程中，在發送端：每層協議棧都會在上層協議的基礎上，添加本層的頭數據或者尾部添加數據。并且，每層添加的協議頭部的數據結構其實也是不一樣的，因為不同層次的協議棧有不同的處理作用，就造成了有不同的需求，所以協議頭當然是不同的。直到封裝數據到最后成以太網幀(在以太網中)，在硬件設備和網絡中進行數據傳送。
在接收端：因為發送端在發送數據會進行協議層封裝，那么接收端就是解封裝。根據每次協議層的規則，拆分協議頭數據進行記錄和處理。直到最后將發送端的應用程序，發送有效數據傳輸到接收端的具體應用中，進行數據處理。
因為不同層次的協議會對數據處理處理，所以，每個對每個層次的數據的稱呼也就不一樣了：
物理層：?比特(bit)
鏈路層：?幀(Frame)
網絡層:?分組數據包(Packet)
傳輸層:?數據段(Segment)
上述兩端的數據通信流程可以通過圖示更加形象的表現處理：
【TCP/IP參考模型】
可以看到，從最頂層的應用程的用戶數據的產生，傳輸到下層TCP，會對數據進行TCP首部封裝成段數據(segment),在往下層網絡層傳輸，該層會添加IP首部，這時候數據就變成了分組數據包，再往下就是主機到以太網的連接層，封裝成以太網幀(frame)，添加以太網首部，尾部等等。最后就可以將整個數據發送到網絡中。
在大致了解了網絡總計算機的數據通信要經過基層協議棧的處理封裝，到最后數據傳輸，再到數據解封到接收端的過程后，就可以對每層的協議進行了解了，看看，每個層次的協議數據結構是怎樣的，每層協議的封裝的協議頭部有什么用，以及每個層次協議棧中有哪些常見的協議，都可以進行了解和學習。
TCP協議棧
在傳輸層中，主要的協議就是TCP以及UDP協議，前者是面向連接的字節流可靠的數據通信協議；后者是無連接的不可靠的協議。其實，這兩種協議在實際應用中都很廣泛，并且內部內容還不少。這里因為是基礎知識內容學習，就打算只是講講tcp協議內容。
什么是TCP（Transmission Control Protocol），可以查看百度TCP。通過名字知道它是傳輸控制協議。就是在主機通信過程中，在傳輸層對數據進行控制處理的協議。這個面向連接的可靠服務的協議，功能還不少，包括數據正確性校驗，超時重傳，窗口流量控制等等。這些功能都是為了支持可靠性而服務的。
TCP數據段數據格式
【1】那么，在傳輸層中，tcp段數據的內部格式是怎么樣的？如下圖：
可以看到，tcp數據在ip數據包中的位置，以及整個tcp段數據的數據格式。
【2】根據上圖的數據段的數據格式，每個位置的字段內容代表什么?
- 源端口和目的端口號: 這兩個字段均為16位長度，表示發送端和接收端的端口，用于確認發送端和接收端的應用程序。發送端的IP地址和端口號以及接收端的IP地址和端口號可以確認一個在internet上的TCP連接（端對端的連接建立）。（PORT + IP : 定位主機與主機上的應用程序）
- 序列號： 序列號是一個32位長度字段，表示分配給TCP包的編號。序列號用來標識應用程序從TCP的發送端到接收端發送的字節流。當TCP開始連接的時候，發送一個序列號給接收端，連接成功后，這個序列號作為初始序列號ISN。之后連接成功發送的第一個字節的序列號位ISN+1,之后發送數據ISN將按照字節的大小進行遞增，當序列號大于2的32次方-后，從0開始。
- 確認號： 發送方對發送的首字節進行了編號，當接收方成功接收后，發送接收成功的序列號加1標識確認回發送端，發送方再次發送的時候就從這個返回的確認號開始。(三次握手)
- 頭部長度： 表示TCP頭部的長度，由于TCP的數據有可選字段，頭部長度用于表示頭部的長度。該項長度位4位，單位是32位字長的數據。TCP的頭部最長為60字節，如果沒有可選字段通常是20個字節。
- 保留位： 6位長度沒有使用，必須設置為0.
-
控制位： 6位長度的控制位，可以多個位一起設置。含義如下表：
1 2 3 4 5 6 7 字段 含義 URG 緊急指針字段 ACK 表示確認號有效 PSH 表示接收方需要盡快將此數據交給應用層 RST 重建連接 SYN 用于發起一個TCP連接 FIN 用于表示將要斷開TCP的連接 -
窗口尺寸： 窗口的尺寸也稱作接收窗口大小，表示本機上TCP協議可以接收的以字節位單位的數目，本字段為16位長度。
- TCP校驗和： 16位長度，用于校驗TCP傳輸數據的正誤，包括TCP頭和所有數據，TCP的數據必須強制校驗。
- 緊急指針： 16位長度，只有設置了URG位為1這個字段數據才會有效，他指出了緊急接收數據的字節的順序編號。
- 選項： 經常使用的為最大分段長度MSS。tcp連接通常在第一個通信的報文中指明這個選項，它指明當前主機所能接收的最大報文長度。
【3】TCP在linux中代碼定義：
為了校驗或者說從程序員的角度來理解這個TCP協議，最直接的方式就是通過底層代碼的方式來看了。那么，在linux系統中，對tcp的定義確實可以看到。
可以查看cat /usr/include/linux/tcp.h可以看到具體的對tcp的數據格式的定義：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 | struct tcphdr { __be16 source; /*源地址端口*/ __be16 dest; /*目的地址端口*/ __be32 seq; /*序列號*/ __be32 ack_seq; /*確認序列號*/ __u16 res1:4, /*保留*/ doff:4, /*偏移（頭部長度）*/ fin:1, /*關閉連接標志*/ syn:1, /*請求tcp連接標志*/ rst:1, /*重置連接標志*/ psh:1, /*接收方盡快將數據推送至應用層*/ ack:1, /*確認序列號標志*/ urg:1, /*緊急指針標志*/ ece:1, /*擁塞標志位*/ cwr:1; /*擁塞標志位*/ __u16 doff:4, res1:4, cwr:1, ece:1, urg:1, ack:1, psh:1, rst:1, syn:1, fin:1; __be16 window; /*滑動窗口大小*/ __sum16 check; /*校驗和*/ __be16 urg_ptr; /*緊急字段指針*/ }; /* * The union cast uses a gcc extension to avoid aliasing problems * (union is compatible to any of its members) * This means this part of the code is -fstrict-aliasing safe now. */ union tcp_word_hdr { struct tcphdr hdr; __be32 words[5]; }; |
?
根據上面的tcp端數據的數據格式和上述代碼定義結合起來理解，可以發現代碼就是按照tcp的數據段的數據格式內容來進行定義的，只不過是區分了內存存儲字節的大端對齊還是小端對齊的方式而已。
TCP連接與釋放
在理解了傳輸層協議棧中tcp協議數據段的內部數據格式，以及格式中每個字段代表的內容。接下來就可以來看看一個tcp連接是如何連接和釋放的。沒錯，就是大名鼎鼎的TCP三次握手和四次揮手。
【1】TCP三次握手
在廣域網或者局域網內，兩臺主機要進行tcp的連接，數據交互，都必須遵循TCP/IP協議模型中tcp連接規則：TCP三次握手。
即tcp是面向字節流的連接，在確認兩個主機可以進行tcp交互的前提是，tcp鏈路連接必須要在數據交互前建立起來。
TCP三次握手，其實就是TCP連接建立的過程，三次握手的目的是同步連接雙方的序列號和確認號并交換TCP窗口大小信息。
因為兩臺主機要進行tcp數據交互，對于每單獨的主機，你得知道雙發對于數據包發送的規則，即從那個包開始發送，有什么標志說明某個數據是第一次發送的數據，什么時候你發送過來的數據是結束數據？每次你那邊能接收到多少字節的數據？所以，三次握手就是為了數據交互做探測準備的。
?
下面來分別說說這個TCP三次握手的細節流程:【主要的就是同步序列號和確認號】
客戶端主機A主動打開，發送連接請求報文段(segment)，將tcp連接標志為SYN值為1，表示要發起一個連接；將seq（序列號:分配給報文段的編號標志）設置為x(TCP規定SYN=1時不能攜帶數據，x為隨機產生的一個值)，然后客戶端狀態進入SYN_SEND。
服務器端B收到A發送過來的報文，進行確認處理，表示收到的序列號有效，設置ACK=1;因為也要發送一個請求連接進行返回，所以SYN=1；因為服務器端B也要發送報文段數據，所以設置報文序列號為seq=y（這個服務器端B主機的報文段序列號，也是為了客戶機A接收到，加1處理設置確認序列號返回用的），這時候，最重要的是設置確認序列號ack，因為在第一步中接收到了主機A發送的序列號x,這時候，接收端需要在接收到的序列號基礎上加1，將值x+1作為確認序列號設置到tcp報文段中，所以設置ack=x+1。表示：我已經收到發來的序列號了，確認序列號為x+1,你下次發送報文段數據的序列號就從x+1開始設置，這樣，我才認可是你發送的數據，才是有效數據。。
客戶端主機A接收服務器端的反饋數據，進行再次確認，若是得到的ack為第一次發送的序列號基礎上加1，那么說明這個報文段是有效的，設置ACK=1;因為不是要求重新發送tcp請求，所以，不用在設置SYN=1了。只是需要校驗確認序列號，這邊確認成功，還要對接收到的服務器端序列號y進行設置，在y基礎上加1，將y+1作為確認序列號設置到報文段的ack字段中，為了讓服務器端進行報文校驗，即設置ack=y+1（當B端接收到報文段后，獲取ack=y+1，說明與上次發送的報文序列號差1，報文段有效），因為確認報文有效了，所以，此時可以將這個發送的報文段的序列號設置為接收來的確認序列號seq=x+1，說明，正式的數據發送已經開始了，從x+1開始的序列號的報文段就是我發送的。
seq序列號表示發送的報文段的報文編號，ack序列號表示對方接收端處理后的確認序列號，用于校驗報文段是否正確的。
在三次握手建立好連接之后，就可以進行正常的數據交互了，當然了，每次數據交互發送的報文段都是又這些例如序列號seq,接收方的確認序列號，控制表示，源和目的端口號等等。
為什么客戶端要進行二次確認？
因為會出現已失效的連接請求報文情況：
正常來說，客戶端發出連接請求，但因為連接請求報文丟失而未收到確認。于是客戶端再次發出一次連接請求，后來收到了確認，建立了連接。數據傳輸完畢后，釋放了連接，客戶端一共發送了兩個連接請求報文段，其中第一個丟失，第二個到達了服務端，沒有”已失效的連接請求報文段”。
現在假定一種異常情況，即客戶端發出的第一個連接請求報文段并沒有丟失，只是在某些網絡節點長時間滯留了，以至于延誤到連接釋放以后的某個時間點才到達服務端。本來這個連接請求已經失效了，但是服務端收到此失效的連接請求報文段后，就誤認為這是客戶端又發出了一次新的連接請求。于是服務端又向客戶端發出請求報文段，同意建立連接。假定不采用三次握手，那么只要服務端發出確認，連接就建立了。
由于現在客戶端并沒有發出連接建立的請求，因此不會理會服務端的確認，也不會向服務端發送數據，但是服務端卻以為新的傳輸連接已經建立了，并一直等待客戶端發來數據，這樣服務端的許多資源就這樣白白浪費了。
采用三次握手的辦法可以防止上述現象的發生。比如在上述的場景下，客戶端不向服務端的發出確認請求，服務端由于收不到確認，就知道客戶端并沒有要求建立連接。
【2】TCP四次揮手
當兩段AB的tcp連接傳輸完成之后，要進行斷開，就像tcp連接要進行三次握手才能正確的傳遞數據；在tcp的斷開也要進行一些規則的流程：TCP四次揮手。
再來看看tcp四次揮手的流程圖:
揮手流程分析:
客戶端A主機在得到或者處理完成數據需求之后，就準備關閉連接了，先會發送一個報文給服務器端B主機(沒有數據)，設置報文控制位FIN=1
，要求斷開連接。該報文序列號seq設置位u,seq=u，客戶端在將該報文發送出去后，就進入FIN_WAIT_1狀態。
服務器端B主機收到了來自客戶端的請求后，校驗確認序列號后設置ACK=1,同時也設置響應報文序列號seq=v，并將接收到的客戶端的報文的序列號+1作為確認序列號，即設置ack=u+1，放回給客戶端主機A，此時服務器端進入了CLOSE_WAIT狀態。（因為步驟一中客戶端A的斷開請求又多種情況，主動權也是在客戶端主機A，那么就會又這種狀況，服務器主機B的應用處理還沒又完成，就收到客戶端的斷開請求，這時候在響應客戶端說，服務器收到了斷開請求，準備斷開后，進入close_wait狀態后，就要通知服務器端的處理程序，要進行斷開了，至于怎么處理就要看程序的控制了。響應請求未發送FIN控制位值）
當通知完服務器端的應用程序，要進行關閉后，服務器端就會被動關閉，就會發送一個斷開請求，FIN=1,并根據上次發送響應報文的確認序列號u+1，又設置同樣的值，這樣，就說明這此FIN斷開請求與上次響應請求是一致的，并同時設置確認序列號有效ACK=1,設置該次請求報文序列號seq=w。這個時候，服務器端進入LAST_ACK狀態，即最后一次發送確認序列號。(這次請求是服務器端關閉應用程序后，在被動關閉的狀態下發送的斷開連接請求。)
客戶端第二次接收到服務器端信息（但是是第一次接收服務器端FIN斷開連接請求），即從報文段中知道FIN=1,即服務器請求斷開連接了，客戶端就會進入TIME_WAIT狀態，接著發送一個確認報文，校驗收到的服務器端的FIN斷開請求，設置ACK=1,報文序列號設置為客戶端的第二次發送，即在第一次發送的seq=u的基礎上再加1，即seq=u+1，同時ack將會設置為從服務器端B主機接收的報文序列號w的基礎上加1，ack=w+1，表明接收到了斷開請求且確認序列號有效。最后，服務器端和客戶端都會進入CLOSE_WAIT狀態。
為什么握手只要三次，揮手卻要四次?
因為服務端在LISTEN狀態下，收到建立請求的SYN報文后，把ACK和SYN放在一個報文里發送給客戶端。而連接關閉時，當收到對方的FIN報文時，僅僅表示對方沒有需要發送的數據了，但是還能接收數據，己方未必數據已經全部發送給對方了，所以己方可以立即關閉，也可以將應該發送的數據全部發送完畢后再發送FIN報文給客戶端來表示同意現在關閉連接。【LAST_ACK表示沒有數據要發送了】
從這個角度而言，再斷開連接的時候，服務端的ACK和FIN一般都會分開發送。
IP協議棧
在TCP/IP參考模型中的網際層中的IP協議棧，在數據傳輸過程中，會對上層的tcp處理后的數據段(segment)，在此進行封裝，加上自己的ip頭部數據。
其中，雖然arp,icmp協議并不是該層的協議，但是兩者在該層中是與ip協議進行協同工作的。即IP層中包含網際控制報文協議和地址識別協議。
前者ICMP用于報告網絡上的某些出錯情況，允許網際路由器傳輸出現差錯信息或者測試報文。
后者ARP處于IP層和數據鏈路層之間，它是用來將32位ip地址與MAC地址轉換用的。
關于ip更詳細的介紹，參考百度ip
IP數據包數據格式
好了，在簡要介紹了網際層的常見協議和作用外，就可以看看該層的數據包中的數據格式和內部字段代表的含義。
【1】數據包數據格式
可以看到，相比較TCP的數據段內的數據格式，ip內部的數據也不少。
【2】字段含義
根據上面一步中的IP數據包內部數據格式，下面可以來分別看看內部的字段分別代表了什么意思。
- 版本號：ip協議的版本號，長度4位，規定網絡實現的IP版本。IPV4該值為4。
- 首部長度： 首部長度指的是IP字段除去數據的整個頭部數據長度，是以32位的字作為計算單位。最短的IP頭部長度是20字節，最長為60個字節。所以該屬性值的可取值范圍是5 - 15。
- 服務類型(TOS): ip服務類型字段長度8位。包括3位優先權，4位T服務類型子字段和1位保留字段:
1 2 3 字段 優先權 D T R F 保留 長度 3位 1位 1位 1位 1位 1位 含義 優先級 延遲 吞吐量 可靠性 費用 未用
其中：后四位字段只能用一個，若是全部為0表示一般服務。服務類型字段由應用程序進行設置，路由器僅在必要的時候進行讀取，不會進行設置。
- 總長度：總長度字段長度16位，表示以字節為單位的數據報文長度，長度包含IP頭部和數據部分。 所以ip數據報文總長度可以到達65535個字節長度。
- 標識和片偏移： IP每次發一份數據報文都會填寫一個標識用來表示此數據包，發送完后此值會加1。所以，在傳輸數據>mtu=1500個字節的時候，需要對數據報文進行分片。在分片的時候，需要對分片的每一個數據設置序號和ip報文來源，都可以在標識種進行設置。還要加上分片數據在源數據報文種的偏移地址，便于接收端收到所有分片的ip數據報進行重新組合。
- 生存時間： TTL(time to live) 字段的值表示數據報文最多可以經過的路由器的數量。源主機發送數據時候設置TTL（一般為32或者64）,沒經過一個
路由器進行分轉，TTL的值減一。當TTL=0的時候，路由器會丟棄此包，并發送一個ICMP報文通知源主機。目的： 防止在數據報傳輸過程種出現錯誤，引起包在Internet的路由器之間不斷循環，因而加入TTL機制限制報文經過的路由總數。 -
協議類型： 該字段為8位長度，即最多可以表示255種協議類型，表示IP上承載的是什么高級協議。目的是為了在網際層種進行封包和解包的過程中，TCP/IP協議棧知道將這些數據包發給那個層的協議棧做相關的處理。協議類型含義如下表:
1 2 3 4 5 6 值 協議類型 1 ICMP 2 TCP 6 IMGP 17 UDP ... -
頭部檢驗和： 校驗和是一個16位長度數值。使用循環冗余校驗生成，其作用是保證IP幀的完整性。發送端發送數據的時候要計算CRC16校驗值，填寫到此
字段中；接收端會計算IP的校驗值并與該字段進行匹配，如果不匹配表示幀發生錯誤，將丟棄此報文。因為CRC16的計算與TTL有關，所以每次經過路由器都要重新計算。 - 源地址和目的地址： 即為發送端和接收端主機的ip地址。
【3】ip數據包在linux中代碼定義:
若是像查看ip數據包在linux中代碼的定義情況，則可以通過命令cat /usr/include/linux/ip.h查看：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | /*IP頭部數據結構的定義*/ struct iphdr { #if defined(__LITTLE_ENDIAN_BITFIELD) /*小端對齊*/ __u8 ihl:4, /*ip頭部長度，單位是32bit*/ version:4; /*IP版本，值為4 IPV4*/ #elif defined (__BIG_ENDIAN_BITFIELD) /*大端*/ __u8 version:4, /*版本 ipv4*/ ihl:4; /*IP頭部長度*/ #else #error "Please fix <asm/byteorder.h>" #endif __u8 tos; /*服務類型*/ __be16 tot_len; /*總長度*/ __be16 id; /*數據報標識*/ __be16 frag_off; /*分片數據片偏移量*/ __u8 ttl; /*生存時間*/ __u8 protocol; /*協議類型：tcp,udp,icmp,imgp*/ __sum16 check; /*頭部校驗和*/ __be32 saddr; /*源主機ip地址*/ __be32 daddr; /*目的主機ip地址*/ /*The options start here. */ /*ip選項*/ }; |
?
可以根據代碼中，定義的變量與ip數據包數據格式中字段進行對比就可以知道，代碼的編寫中變量的定義就是參考ip數據包格式來的。
以太網
在發送端，數據通過應用層到傳輸層，網際IP層，最后越是貼近物理層，封裝成以太網幀(以太網中)進行傳輸。再來看看這個幀內部信息。
以太網幀數據格式
【1】以太網幀數據格式如下圖:
可以看到，以太網幀的數據格式挺簡單的。包括以太網頭部中的：目的mac,源mac,類型。mac代表當前主機和通信主機的硬件地址。類型，則是用于表明當前幀是什么類型的數據幀，是ip數據包，還是arp請求等等。后面還有個以太網尾部CRC,4個字節用來做循環冗余校驗的。
其中，通過以太網幀中的數據長度46~1500，就涉及到一個概念MTU，也就是最大傳輸單元，表明單個幀數據最多能傳輸1500個字節數據(不包括頭部數據)。
【2】幀在linux代碼中的定義：
若是想查看linux中，是如何對以太網幀進行代碼定義的話，可以通過命令cat /usr/include/linux/if_ether.h來查看，可以看到幀的全部字段和類型數據：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 | #ifndef _LINUX_IF_ETHER_H #define _LINUX_IF_ETHER_H #include <linux/types.h> /* * IEEE 802.3 Ethernet magic constants. The frame sizes omit the preamble * and FCS/CRC (frame check sequence). */ #define ETH_ALEN 6 /* Octets in one ethernet addr 以太網地址：mac地址 */ #define ETH_HLEN 14 /* Total octets in header. 以太網頭部的總長度：源地址+目的地址+數據類型 */ #define ETH_ZLEN 60 /* Min. octets in frame sans FCS 不含CRC校驗的數據最小長度：46+12+2 */ #define ETH_DATA_LEN 1500 /* Max. octets in payload 幀內數據的最大長度MTU*/ #define ETH_FRAME_LEN 1514 /* Max. octets in frame sans FCS 不含CRC校驗和的最大以太網數據長度*/ #define ETH_FCS_LEN 4 /* Octets in the FCS CRC校驗和字段長度*/ /* * These are the defined Ethernet Protocol ID's. 下面定義的是以太網頭部中類型字段選址：代表不同的數據類型 2個字節 2^16種類型 */ #define ETH_P_LOOP 0x0060 /* Ethernet Loopback packet */ #define ETH_P_PUP 0x0200 /* Xerox PUP packet */ #define ETH_P_PUPAT 0x0201 /* Xerox PUP Addr Trans packet */ #define ETH_P_TSN 0x22F0 /* TSN (IEEE 1722) packet */ #define ETH_P_IP 0x0800 /* Internet Protocol packet 表示IP數據報文 */ #define ETH_P_X25 0x0805 /* CCITT X.25 */ #define ETH_P_ARP 0x0806 /* Address Resolution packet ARP協議數據類型*/ #define ETH_P_BPQ 0x08FF /* G8BPQ AX.25 Ethernet Packet [ NOT AN OFFICIALLY REGISTERED ID ] */ #define ETH_P_IEEEPUP 0x0a00 /* Xerox IEEE802.3 PUP packet */ #define ETH_P_IEEEPUPAT 0x0a01 /* Xerox IEEE802.3 PUP Addr Trans packet */ #define ETH_P_BATMAN 0x4305 /* B.A.T.M.A.N.-Advanced packet [ NOT AN OFFICIALLY REGISTERED ID ] */ #define ETH_P_DEC 0x6000 /* DEC Assigned proto */ #define ETH_P_DNA_DL 0x6001 /* DEC DNA Dump/Load */ #define ETH_P_DNA_RC 0x6002 /* DEC DNA Remote Console */ #define ETH_P_DNA_RT 0x6003 /* DEC DNA Routing */ #define ETH_P_LAT 0x6004 /* DEC LAT */ #define ETH_P_DIAG 0x6005 /* DEC Diagnostics */ #define ETH_P_CUST 0x6006 /* DEC Customer use */ #define ETH_P_SCA 0x6007 /* DEC Systems Comms Arch */ #define ETH_P_TEB 0x6558 /* Trans Ether Bridging */ #define ETH_P_RARP 0x8035 /* Reverse Addr Res packet */ #define ETH_P_ATALK 0x809B /* Appletalk DDP */ #define ETH_P_AARP 0x80F3 /* Appletalk AARP */ #define ETH_P_8021Q 0x8100 /* 802.1Q VLAN Extended Header */ #define ETH_P_IPX 0x8137 /* IPX over DIX */ #define ETH_P_IPV6 0x86DD /* IPv6 over bluebook */ #define ETH_P_PAUSE 0x8808 /* IEEE Pause frames. See 802.3 31B */ #define ETH_P_SLOW 0x8809 /* Slow Protocol. See 802.3ad 43B */ #define ETH_P_WCCP 0x883E /* Web-cache coordination protocol * defined in draft-wilson-wrec-wccp-v2-00.txt */ #define ETH_P_MPLS_UC 0x8847 /* MPLS Unicast traffic */ #define ETH_P_MPLS_MC 0x8848 /* MPLS Multicast traffic */ #define ETH_P_ATMMPOA 0x884c /* MultiProtocol Over ATM */ #define ETH_P_PPP_DISC 0x8863 /* PPPoE discovery messages */ #define ETH_P_PPP_SES 0x8864 /* PPPoE session messages */ #define ETH_P_LINK_CTL 0x886c /* HPNA, wlan link local tunnel */ #define ETH_P_ATMFATE 0x8884 /* Frame-based ATM Transport * over Ethernet */ #define ETH_P_PAE 0x888E /* Port Access Entity (IEEE 802.1X) */ #define ETH_P_AOE 0x88A2 /* ATA over Ethernet */ #define ETH_P_8021AD 0x88A8 /* 802.1ad Service VLAN */ #define ETH_P_802_EX1 0x88B5 /* 802.1 Local Experimental 1. */ #define ETH_P_TIPC 0x88CA /* TIPC */ #define ETH_P_MACSEC 0x88E5 /* 802.1ae MACsec */ #define ETH_P_8021AH 0x88E7 /* 802.1ah Backbone Service Tag */ #define ETH_P_MVRP 0x88F5 /* 802.1Q MVRP */ #define ETH_P_1588 0x88F7 /* IEEE 1588 Timesync */ #define ETH_P_NCSI 0x88F8 /* NCSI protocol */ #define ETH_P_PRP 0x88FB /* IEC 62439-3 PRP/HSRv0 */ #define ETH_P_FCOE 0x8906 /* Fibre Channel over Ethernet */ #define ETH_P_TDLS 0x890D /* TDLS */ #define ETH_P_FIP 0x8914 /* FCoE Initialization Protocol */ #define ETH_P_80221 0x8917 /* IEEE 802.21 Media Independent Handover Protocol */ #define ETH_P_HSR 0x892F /* IEC 62439-3 HSRv1 */ #define ETH_P_LOOPBACK 0x9000 /* Ethernet loopback packet, per IEEE 802.3 */ #define ETH_P_QINQ1 0x9100 /* deprecated QinQ VLAN [ NOT AN OFFICIALLY REGISTERED ID ] */ #define ETH_P_QINQ2 0x9200 /* deprecated QinQ VLAN [ NOT AN OFFICIALLY REGISTERED ID ] */ #define ETH_P_QINQ3 0x9300 /* deprecated QinQ VLAN [ NOT AN OFFICIALLY REGISTERED ID ] */ #define ETH_P_EDSA 0xDADA /* Ethertype DSA [ NOT AN OFFICIALLY REGISTERED ID ] */ #define ETH_P_AF_IUCV 0xFBFB /* IBM af_iucv [ NOT AN OFFICIALLY REGISTERED ID ] */ #define ETH_P_802_3_MIN 0x0600 /* If the value in the ethernet type is less than this value * then the frame is Ethernet II. Else it is 802.3 */ /* * Non DIX types. Won't clash for 1500 types.【MTU】 */ #define ETH_P_802_3 0x0001 /* Dummy type for 802.3 frames */ #define ETH_P_AX25 0x0002 /* Dummy protocol id for AX.25 */ #define ETH_P_ALL 0x0003 /* Every packet (be careful!!!) */ #define ETH_P_802_2 0x0004 /* 802.2 frames */ #define ETH_P_SNAP 0x0005 /* Internal only */ #define ETH_P_DDCMP 0x0006 /* DEC DDCMP: Internal only */ #define ETH_P_WAN_PPP 0x0007 /* Dummy type for WAN PPP frames*/ #define ETH_P_PPP_MP 0x0008 /* Dummy type for PPP MP frames */ #define ETH_P_LOCALTALK 0x0009 /* Localtalk pseudo type */ #define ETH_P_CAN 0x000C /* CAN: Controller Area Network */ #define ETH_P_CANFD 0x000D /* CANFD: CAN flexible data rate*/ #define ETH_P_PPPTALK 0x0010 /* Dummy type for Atalk over PPP*/ #define ETH_P_TR_802_2 0x0011 /* 802.2 frames */ #define ETH_P_MOBITEX 0x0015 /* Mobitex (kaz@cafe.net) */ #define ETH_P_CONTROL 0x0016 /* Card specific control frames */ #define ETH_P_IRDA 0x0017 /* Linux-IrDA */ #define ETH_P_ECONET 0x0018 /* Acorn Econet */ #define ETH_P_HDLC 0x0019 /* HDLC frames */ #define ETH_P_ARCNET 0x001A /* 1A for ArcNet :-) */ #define ETH_P_DSA 0x001B /* Distributed Switch Arch. */ #define ETH_P_TRAILER 0x001C /* Trailer switch tagging */ #define ETH_P_PHONET 0x00F5 /* Nokia Phonet frames */ #define ETH_P_IEEE802154 0x00F6 /* IEEE802.15.4 frame */ #define ETH_P_CAIF 0x00F7 /* ST-Ericsson CAIF protocol */ #define ETH_P_XDSA 0x00F8 /* Multiplexed DSA protocol */ /* * This is an Ethernet frame header. */ struct ethhdr { unsigned char h_dest[ETH_ALEN]; /* destination eth addr 以太網目的Mac地址 */ unsigned char h_source[ETH_ALEN]; /* source ether addr 以太網源MAC地址*/ __be16 h_proto; /* packet type ID field 以太網包類型：16位*/ } __attribute__((packed)); #endif /* _LINUX_IF_ETHER_H */ |
?
硬件設備
不同層次對應的硬件配置：（通常情況下，不包括三層交換機，四層交換機..）
物理層：網卡，網線，集線器，中繼器，調制解調器
數據鏈路層：網橋，交換機
網絡層：路由器
網關工作在第四層傳輸層及其以上
集線器是物理層設備,采用廣播的形式來傳輸信息。
交換機就是用來進行報文交換的機器。多為鏈路層設備(二層交換機)，能夠進行地址學習，采用存儲轉發的形式來交換報文.。
路由器的一個作用是連通不同的網絡，另一個作用是選擇信息傳送的線路。選擇通暢快捷的近路，能大大提高通信速度，減輕網絡系統通信負荷，節約網絡系統資源，提高網絡系統暢通率。
交換機和路由器的區別?
交換機擁有一條很高帶寬的背部總線和內部交換矩陣。交換機的所有的端口都掛接在這條總線上，控制電路收到數據包以后，處理端口會查找內存中的地址對照表以確定目的MAC（網卡的硬件地址）的NIC（網卡）掛接在哪個端口上，通過內部交換矩陣迅速將數據包傳送到目的端口，目的MAC若不存在則廣播到所有的端口，接收端口回應后交換機會“學習”新的地址，并把它添加入內部MAC地址表中。
使用交換機也可以把網絡“分段”，通過對照MAC地址表，交換機只允許必要的網絡流量通過交換機。通過交換機的過濾和轉發，可以有效的隔離廣播風暴，減少誤包和錯包的出現，避免共享沖突。
交換機在同一時刻可進行多個端口對之間的數據傳輸。每一端口都可視為獨立的網段，連接在其上的網絡設備獨自享有全部的帶寬，無須同其他設備競爭使用。當節點A向節點D發送數據時，節點B可同時向節點C發送數據，而且這兩個傳輸都享有網絡的全部帶寬，都有著自己的虛擬連接。假使這里使用的是10Mbps的以太網交換機，那么該交換機這時的總流通量就等于2×10Mbps＝20Mbps，而使用10Mbps的共享式HUB時，一個HUB的總流通量也不會超出10Mbps。
總之，交換機是一種基于MAC地址識別，能完成封裝轉發數據包功能的網絡設備。交換機可以“學習”MAC地址，并把其存放在內部地址表中，通過在數據幀的始發者和目標接收者之間建立臨時的交換路徑，使數據幀直接由源地址到達目的地址。
從過濾網絡流量的角度來看，路由器的作用與交換機和網橋非常相似。但是與工作在網絡物理層，從物理上劃分網段的交換機不同，路由器使用專門的軟件協議從邏輯上對整個網絡進行劃分。例如，一臺支持IP協議的路由器可以把網絡劃分成多個子網段，只有指向特殊IP地址的網絡流量才可以通過路由器。對于每一個接收到的數據包，路由器都會重新計算其校驗值，并寫入新的物理地址。因此，使用路由器轉發和過濾數據的速度往往要比只查看數據包物理地址的交換機慢。但是，對于那些結構復雜的網絡，使用路由器可以提高網絡的整體效率。路由器的另外一個明顯優勢就是可以自動過濾網絡廣播。
集線器與路由器在功能上有什么不同?
首先說HUB,也就是集線器。它的作用可以簡單的理解為將一些機器連接起來組成一個局域網。而交換機（又名交換式集線器）作用與集線器大體相同。但是兩者在性能上有區別：集線器采用的式共享帶寬的工作方式，而交換機是獨享帶寬。這樣在機器很多或數據量很大時，兩者將會有比較明顯的。而路由器與以上兩者有明顯區別，它的作用在于連接不同的網段并且找到網絡中數據傳輸最合適的路徑。路由器是產生于交換機之后，就像交換機產生于集線器之后，所以路由器與交換機也有一定聯系，不是完全獨立的兩種設備。路由器主要克服了交換機不能路由轉發數據包的不足。
總的來說，路由器與交換機的主要區別體現在以下幾個方面：
（1）工作層次不同
最初的的交換機是工作在數據鏈路層，而路由器一開始就設計工作在網絡層。由于交換機工作在數據鏈路層，所以它的工作原理比較簡單，而路由器工作在網絡層，可以得到更多的協議信息，路由器可以做出更加智能的轉發決策。
（2）數據轉發所依據的對象不同
交換機是利用物理地址或者說MAC地址來確定轉發數據的目的地址。而路由器則是利用IP地址來確定數據轉發的地址。IP地址是在軟件中實現的，描述的是設備所在的網絡。MAC地址通常是硬件自帶的，由網卡生產商來分配的，而且已經固化到了網卡中去，一般來說是不可更改的。而IP地址則通常由網絡管理員或系統自動分配。
（3）傳統的交換機只能分割沖突域，不能分割廣播域；而路由器可以分割廣播域
由交換機連接的網段仍屬于同一個廣播域，廣播數據包會在交換機連接的所有網段上傳播，在某些情況下會導致通信擁擠和安全漏洞。連接到路由器上的網段會被分配成不同的廣播域，廣播數據不會穿過路由器。雖然第三層以上交換機具有VLAN功能，也可以分割廣播域，但是各子廣播域之間是不能通信交流的，它們之間的交流仍然需要路由器。
（4）路由器提供了防火墻的服務
路由器僅僅轉發特定地址的數據包，不傳送不支持路由協議的數據包傳送和未知目標網絡數據包的傳送，從而可以防止廣播風暴。
該部分截取自:OSI七層模型詳解
總結
上面的內容僅僅是網絡的很小很小的基礎知識部分，也是自己學習過程中一些總結。包括數據通信的OSI/TCP參考模型，并對數據通信中每層的協議棧進行分析和內部數據結構的圖解，同時也將linux系統對每層協議的代碼定義也羅列出來，幫助程序員加深理解。其實，內部還有很多東西值得去學習，分析，思考。這篇就到這….
參考：
Liux網絡編程(第二版)
TCP：三次握手、四次握手、backlog及其他
?
轉載于:https://www.cnblogs.com/liujiacai/p/8326065.html
總結
以上是生活随笔為你收集整理的(转)计算机网络基础知识总结的全部內容，希望文章能夠幫你解決所遇到的問題。
