本文只是表達個人對http概念，get、post方法，http各大版本以及https、socket的理解。如有問題，歡迎指正
一、TCP/UDP的概念
TCP可以理解爲是一個協議組或者是一個網絡服務模型。是基於連接的協議，在收發數據前，需要建立可靠的連接，也就是所謂的三次握手。使用TCP協議時，數據會準確到達，但是效率較低
UDP是面向非連接的協議，它不與對方建立連接，而是直接就把數據包發送過去。使用UDP協議時，傳輸效率高，但是不能保證數據準確到達
網絡層：有IP協議、ICMP協議、ARP協議、RARP協議和BOOTP協議。
傳輸層：有TCP協議與UDP協議。
應用層：有FTP、HTTP、TELNET、SMTP、DNS等協議
二、HTTP
HTTP全稱超文本傳輸協議，是基於tcp/ip協議，屬於應用層協議
http非常的寬鬆，只是定義了大的標準，至於遵守還是修改，只看個人！這句話很重要，很重要，很重要
特點：
1、請求/響應模型，客戶端發起請求，服務器響應。
2、無狀態。每個請求都是獨立的，互不影響。即使相同的客戶端發起相同的請求，也是完全獨立的。http不會爲了下一次連接而維護這次連接所傳輸的信息
3、無連接。每次連接只處理一個請求。連接->傳輸數據->關閉連接 。客戶端跟服務端完成了一次http交互流程後，便關閉連接。
但是1.1後會有keep-alive，下面會講到
4、明文傳輸。http協議不會對傳輸的信息進行加密。這裏可能會有個疑問，http是二進制傳遞數據的，我們對傳輸的數據進行加密，怎麼就是明文傳輸的呢？其實明文在此處只是相對的。http非常的寬鬆。給予了傳輸管道而不對管道中的東西做任何加密處理，這就是http的明文傳輸標準。至於你自己對數據加密，我不知道，不管。如果自己對數據加密就宣稱某某某加密傳輸協議，不說其他的，http協議都能被叫出無限的某某某加密協議了
三、HTTP1.0、1.1、2.0
1、HTTP1.0
在HTTP1.0中，客戶端每發送一次請求都需要新建一個獨立的連接，客戶端得到服務端響應後再斷開本次連接。
每次請求都握手、建立鏈接，這非常的浪費時間
HTTP1.0只有GET POST和HEAD方法
2、HTTP1.1
在HTTP1.1中，打印請求的header，會發現Connection:keep-alive，默認持久鏈接。如果是close時，客戶端通知服務器返回本次請求結果後關閉連接。這意味着可以在一次連接中處理多次請求，大大節省了時間和性能。
儘管有 Keep-Alive 機制可以複用，但在每個連接上同時只能有一個請求 / 響應，這意味着完成響應之前，這個連接不能用於其他請求。可以理解爲請求隊列，同時只能處理一個請求，先進先出。
HTTP1.1增加5個新的方法：OPTIONS，PUT，DELETE，TRACE和CONNEC
3、HTTP2.0
1、HTTP2.0是完全多路複用的，而非有序並阻塞的
在HTTP1.1中，瀏覽器客戶端在同一時間，針對同一域名下的請求有一定數量的限制。超過限制數目的請求會被阻塞。而多路複用是基於二進制分幀層，既在共享TCP鏈接的基礎上同時發送請求和響應。HTTP消息被分解爲獨立的幀，而不破壞消息本身的語義，交錯發出去，在另一端根據流標識符和首部將他們重新組裝起來
3、HTTP2.0讓服務器可以將響應主動“推送”到客戶端
服務端根據客戶端的請求，提前返回多個響應，推送額外的資源給客戶端。比如客戶端請求A，但是服務端可以返回A和額外的B，C等。但是需要注意所有推送的資源都必須遵守同源策略。既需要雙方確認，纔可以推送。
。。。。省略N字，還有很多
四、GET、POST
1、get請求參數拼接在URL後面，只能進行url編碼，會被瀏覽器主動cache，傳遞的參數有長度限制。。。
2、post請求參數放在Request body中。不會被瀏覽器cache，除非另行設置。傳輸數據多樣化。。。
然後，只是這些麼？
http有Header、Body。
Header最常見的Content-Type：application/json、Content-Type：image/jpg等
Body有form-data、x-www-form-urlencoded、raw等格式
https://blog.csdn.net/u013827143/article/details/86222486
x-www-form-urlencoded：爲默認缺省值，鍵值隊傳遞參數，然而向服務器發送大量的文本、包含非ASCII字符的文本或二進制數據時這種編碼方式效率很低
form-data：鍵值隊傳遞參數，可以傳遞多個文件
raw：可以上傳任意格式的數據，json、xml、html等。然後沒有key，所有一次只能傳遞一條文本數據。比如一次只能傳遞一張圖片
但是但是，上面說了http非常的寬鬆，只是定義了大的標準
假如我Header設置Content-Type：application/xml 但是Body設置raw 傳遞json數據 可以麼？
假如我Body設置raw 傳遞多張圖片數據，自己在數據中設置分隔符區分 可以麼？
可以，也不可以
服務端可以收到和解析你的數據，你跟服務器商量好，都是可以的。
但是這不符合http的標準。有大的標準給你，爲什麼非得走自己的小標準呢。項目組人員多，跨應用對接，誰心裏會沒有千萬顆草呢
get方法一樣可以設置requrest body 傳遞參數
post方法一樣可以設置參數拼接在url後面
只是這樣瀏覽器怎麼cache你的get請求呢？一般瀏覽器是根據url爲key來cache。並且有的瀏覽器會讀取你get請求中request body，有的會忽略，不能保證一定能被接收到
在Android中，一些網絡框架爲了規範，禁止get中設置requrest body
至於PUT，DELETE等方法跟POST有啥區別，暫時沒有研究過。現在只能說信仰，對標準的信仰
五、HTTPS
基於HTTP協議，通過SSL或TLS提供加密處理數據、驗證對方身份以及數據完整性保護。具體流程以及多了幾次握手，可以自行百度
六、SOCKET
socket長連接，套接字。
這個長連接跟http1.1的長連接又有什麼區別呢？
http上面說了是請求/響應模型。客戶端主動要，服務端被動給。但是socket長鏈接卻是平等的，客戶端和服務端能互傳信息。
http請求和響應不會對通信方進行確認、無法保護數據的完整性。
socket一般採用tcp/ip
tpc/ip 通過IP能定位到一臺服務器。但是服務器不可能專爲你一個人服務。OK，那我們再來定義個socket，這個socket只爲你服務，服務端再跟B定義個socket，這個又只爲B服務。所以就形成了tpc/ip +socket
socket一般用來處理 服務端與客戶端交互頻繁並且即時的業務 如即時聊天，股票、醫療等
socket需要開發者注意消息包頭、包體、斷點續傳、心跳包、丟包等系列問題。推薦使用xmpp二次開發
socket寫得好很流弊，寫得不好，會非常。。。你懂的
寫到此處，想起N年前開發的醫療心電項目。後續有時間寫出來，給自己一個備份