如何通俗地解釋TCP和UDP協議和HTTP、FTP、SMTP等協議之間的區別？
HTTP協議
老王喜歡看島國小片，時常泡在論壇上和網友交流最新資訊，老王是通過瀏覽器瀏覽網頁的，而瀏覽器是藉助HTTP協議與論壇伺服器溝通交流。 FTP協議老王購買了該網站的會員，可以無限制下載高清小片，老王是通過瀏覽器下載影音文件的，瀏覽器是藉助FTP協議與文件下載伺服器溝通交流。SMTP協議近10個G的高清文件，老王心潮澎湃打開文件，傻了，「孫悟空大戰白骨精」映入眼簾。。。老王怒了，打開電子郵件客戶端寫投訴郵件，怒斥不良網站的欺詐行為！電子郵件客戶端是藉助SMTP協議與郵件伺服器溝通交流。
通常稱與人類直接打交道的協議，叫應用層（Application）協議，或者業務層協議。上文的三個協議對應三種業務：
- 瀏覽網頁
- 下載文件
- 發送郵件
問題來了，
- 應用數據塊如何在浩瀚的互聯網準確無誤找到目的地？
- 伺服器回應數據塊如何在浩瀚的互聯網準確無誤地返回？
- 應用數據塊在到達目的地之前丟失了，如何處理？
- 伺服器回應數據塊旅途中丟失了，如何處理？
IP協議
在應用數據塊的外層寫上目的地IP地址，使得應用數據塊可以找到目的地，這樣就解決問題1。 還會在應用數據塊的外層寫上源IP地址，使得伺服器回應數據塊返回源主機，這樣就解決問題2。
擡槓的同學會說，應用數據塊外層寫上目的IP地址，就一定可以到達目的地？不一定吧！
把老王的網線拔了、無線關了、移動網路4G也關了，把老王的所有訪問互聯網的通道全關閉了，應用數據塊還能到達目的地哇？ 那肯定不能到達，神仙來了也愛莫能助！ 所以在這裡這種強調兩點：
- 底層物理網路的連通性是IP能否正常工作的前提
- IP路由表在全球路由器裏完成了同步
信號傳輸過程失真造成丟包、網路發生擁堵而丟包。。。
我們還需要一個協議，這個協議需要有以下特質：- 當丟包發生時，能夠自動修復丟包，而無需人的手動幹預
- 能夠智能感知網路的擁堵情況，網路空閑時，盡最大速率發包；網路擁堵時，降低速率發包，不給互聯網添堵
TCP協議也不是什麼大神，不過是一個任勞任怨的流量調度員。說到底它就有一個本事：確認機制！ 憑著這個看家本領，TCP可以保證應用數據的可靠傳輸。 也正是這個確認機制，讓千千萬萬個學習TCP協議的同學，苦苦掙扎痛不欲生！ 但願有同學讀完這篇文章，快速脫離苦海。。。
TCP確認機制通俗地說，TCP會對發出的數據包（以下簡稱包裹）進行編號，如同快遞的快遞單號一樣。對方TCP收到包裹，會回復一個確認消息，確認收到了該編號的包裹了。 這非常好理解，生活裏這樣的故事每天都在發生。男生給異地的女友快遞一個包裹，記下快遞單號123456，過兩天女友回復一個消息，快遞單號123456已收到！ 有同學會說，確認機制可以理解，TCP發數據就發數據，但為何TCP發數據之前需要連接？ 在互聯網上可以找到各種各樣的解釋，而我的觀點是：
雙方通過TCP連接，分享彼此的應用數據塊第一個位元組的原點序號。 如果TCP沒有提前分享，接收方不知道接收的數據是否是第一個包。 如果不是第一個包，接收方的TCP卻將該數據包提交給應用程序，應用程序壓根無法理解。 為何無法理解？應用程序以為是第一個包，其實並不是，應用程序的小翻譯（HTTP/FTP/SMTP）瞬間懵逼，風雨中瑟瑟發抖。。。 分享了原點序列號，即使第二個、第三個數據包先到達目的地，而第一個數據包姍姍來遲的情況，接收方的TCP可以耐心等待第一個數據包的到來，然後按序將數據包提交給應用程序。這樣應用程序的小翻譯就會秒懂。。。 有了TCP協議的幫助，即使老王的網線拔掉了一段時間，稍後再插入，恢復了網路連通性，老王中斷的文件下載任務可以繼續工作，而無需老王重新下載。 UDP協議UDP有點像街頭的郵筒，應用程序的數據包扔進郵筒就好了，就耐心地等待數據包到達目的地。但扔進郵筒之前，需要寫好以下信息：
- 收件人的地址（目的IP）
- 收件人的姓名（目的埠號）
- 寄件人地址（源IP）
- 寄件人姓名（源埠號）
更多文章：https://mp.weixin.qq.com/s/5jwwUsormXxCqkBNp8Qaiw
推薦閱讀：
