1）原理不同
http協議運行於TCP之上，明文傳輸，客戶端和服務端都無法驗證對方身份
https是身披SSL（Secure Socket Layer）外殼的http，運行於SSL之上，是添加了加密和認證機制的http
2）端口不同：http使用的是80端口，https使用的是443端口
3）資源消耗不同：和http通信相比，https會由於加密解密出來消耗更多的cpu資源和內存
4）開銷：https通信需要證書，證書需要向認證機構購買
httpd的加密機制是一種共享密鑰加密和公開公鑰加密並用的混合加密機制
對稱密鑰加密是指加密和解密使用同一個密鑰的方式，這種方式存在的最大問題就是密鑰的發送問題，即任何將密鑰安全的發送給對方，而非對稱密鑰加密是指使用一對非對稱密鑰，即公鑰和私鑰，公鑰可以隨意發布，但是私鑰只有自己知道，發送密文的一方使用對方的公鑰進行加密處理，對方接收到加密信息之后，使用自己的私鑰進行解密
由於非對稱加密的方式不需要發送用來解密的私鑰，所以可以保證安全性，但是和對稱加密比起來，它非常的慢，所以我們還是要用對稱加密的方式發送信息，加密的密鑰可以通過非對稱加密的方式發送出去
1)三次握手（我要和你建立連接，你真的要和我建立連接嗎？我真的要和你建立連接，成功）
*第一次握手：客戶端：發送序號200（隨機的），標志位SYN=1
*第二次握手（建立接收緩沖區）：服務器端：發送序號500（隨機的），確認序號200+1，標志位SYN=1，ACK=1
*第三次握手（建立發送緩沖區）：客戶：發送序號=201，確認序號=500+1，標志位ACK=1
要發送的發送序號=上一次接收到的確認序號
要發送的確認序號=上一次的發送序號+1
2）四次揮手（我要和你斷開連接；好吧，斷吧，但要先等我發完剩余數據；剩余數據發完了，我也要和你斷開連接；好吧，斷吧）
*第一次揮手：客戶：發送序號=200，標志位FIN=1
*第二次揮手（釋放接收緩沖區）：服務端：發現接收到的FIN=1，就發送序號=500，確認序號=200+1，標志位ACK=1
*第三次揮手（釋放發送緩沖區）：服務器：發送序號=300，確認序號=200+1，標志位FIN=1，ACK=1
*第四次揮手：客戶：發送序號=201，確認序號=300+1，標志位ACK=1
為了防止已經失效的連接請求報文突然又傳送到了服務器端（網絡堵塞的原因）
如果客戶端發出的連接請求報文並未丟失而是在某個網絡結點長時間堵塞了，導致延誤到連接釋放以后的某個時間才到達服務器，這時服務器誤以為是客戶端發出了一個新的連接請求，於是就向客戶端發送確認數據包，同意建立連接，如果不采用三次握手，那么只要服務器端發送確認數據包，連接就建立成功了，由於客戶端並未發出連接請求，所以不會理睬服務器的確認，也不與服務器通信，而這個時候服務器一直在等待客戶端發送數據，這樣服務器就白白浪費了資源，如果采用三次握手，那么服務器端密鑰收到來自客戶端的確認，就知道客戶端並沒有請求建立連接，就不會建立連接
三次和四次的區別就在於服務器連續給客戶端發了兩個報文，那把這兩個報文合並成一個不可以嗎？為什么呢？答案是不可以，首先客戶端發來請求斷開連接的報文，假設這個時候服務器端仍然在發送報文（因為是全雙工），如果是三次揮手，那么服務器只會確認客戶的斷開請求，客戶端不會說我還有數據沒有發送完，你要等等我，這樣會導致客戶端接收的數據不完整，如果是四次揮手，那么服務器接收到客戶的斷開請求，會先說可以斷開，但是你要先等我發送完剩余的數據，然后說我剩余的數據發送完了，我要和你斷開連接
揮手過程之所以比握手過程多一次，就是因為握手過程只需要處理連接，而揮手過程需要處理連接和數據！！
TCP提供一種面向連接的，可靠的字節流服務，其中，面向連接意味着兩個使用TCP的應用在彼此交換數據之前必須先建立一個TCP連接，在一個TCP中，僅有兩方進行彼此通信，而字節流服務意味着兩個應用程序通過TCP連接交換8比特字節構成的字節流，TCP不在字節流中插入記錄標識符
對於可靠性，TCP通過以下方式保證：
1）數據包校驗：目的是檢測數據在傳輸過程中的任何變化，若校驗包出錯，則丟棄報文段並且不給出響應，這時TCP數據發送端超時重發數據
2）對失序數據包重排序：既然TCP報文段作為IP數據報來傳輸，而IP數據報的到達可能會失序，因此TCP報文段到達也可能會失序，TCP將失序數據重排序才交給應用層
3）丟棄重復數據
4）應答機制：當TCP收到一個報文就發送一個確認信號
5）超時重傳：一個TCP報文段發送出去后，啟動計時器，到達某個時間沒有收到確認信號就重傳該報文段
6）流量控制：TCP連接的每一方都有一塊固定大小的緩沖空間，TCP的接收端只允許另一端發送接收端緩沖區能容納的數據，這樣可以防止較快主機使得較快主機緩沖區溢出，同樣也能避免網絡擁塞，TCP使用的流量控制協議就是可變大小的滑動窗口協議
服務器會為每個請求創立一個連接，並向其發送確認報文，然后等待客戶端進行確認
1）DDOS攻擊
*客戶端向服務端發送請求數據包
*服務端向客戶端發送確認數據包
*客戶端不向服務端發送確認數據包，服務器一直等待客戶端的確認
2）DDOS攻擊的預防（沒有辦法根治，除非不使用TCP）
*限制同時打開的SYN半連接數目
*縮短SYN半連接的Time Out時間
*關閉不必要服務
get和post是http所屬的方法，而http又是基於TCP/IP實現的，所以get和post的底層都是TCP/IP協議，只不過http定義的規則和瀏覽器的限制導致他們在應用上存在一定的區別，最重要的區別就是get產生一個TCP數據包，而post產生兩個TCP數據包，對於get的請求，瀏覽器會把瀏覽器的header和data一起發送出去，服務器響應200，對於post，瀏覽器先發送header，瀏覽器響應100，瀏覽器再發送data，服務器響應200，也就是說get只需要汽車跑一趟就把貨送到了，而post需要跑兩趟，第一趟先去和服務器打個招呼告訴它我等下要送貨過來，開門迎接我，第二趟就是把貨送過去，據研究，在網絡環境好的情況下，發一次包的時間和發兩次包的時間查基本可以無視，而在網絡環境差的情況下，兩次包的TCP在驗證數據包完整性上有很大的優勢，所以不推薦使用get來優化性能，當然，並不是所有的瀏覽器都會在post中發兩次tcp包，火狐瀏覽器就只發一次
下面我們看看get和post應用上的區別：
*get的參數通過URL傳遞，post放在request body中
*get在URL中的參數是有長度限制的，而post沒有
*get只能進行URL編碼，而post支持多種
*get只接受ASSIC字符，而post沒有限制
*post比get安全，因為get的參數暴露在URL中
1）TCP面向連接，而UDP是無連接的
2）TCP可靠，UDP不可靠
3）TCP只支持點對點通信，而UDP支持1對1，1對多，多對1，多對多的通信模式
4）TCP是面向字節流的，UDP是面向報文的
5）TCP有擁塞控制，UDP沒有擁塞控制，適合媒體通信
6)TCP首部開銷（20字節）比UDP首部開銷（8個字節）要大
擁塞控制就是防止過多的數據注入網絡，造成網絡堵塞，擁塞控制和流量控制不同，擁塞控制是一個全局性過程，而流量控制是點對點通信的控制，擁塞控制的方法主要有以下5種：
1）擁塞窗口：動態窗口，和網絡擁塞程度有關，網絡擁塞程度大，擁塞窗口就小
2）慢啟動：不要一開始就發送大量數據，先探測一下網絡的擁塞程度，也就是說從小到大逐漸增加擁塞窗口的大小
3）擁塞避免（AMDI：加法增大乘法減小）：讓擁塞窗口緩慢增大，每經過一個往返時間就將擁塞窗口+1,緩慢增大擁塞窗口
4）快重傳：發送方只要一收到三個重復的確認就應該立即重傳對方並未收到的報文段，而不必繼續等待重傳計時器到達重傳時間，快重傳並不是取消重傳計時器，而是在某些情況下更早的重傳丟失的報文
5）快恢復：根據收到的重復的ACK的多少調節慢開始門限值ssthresh
1）瀏覽器查詢DNS，獲得域名對應的IP地址
*先從瀏覽器緩存找ip，因為瀏覽器會緩存DNS記錄一段時間
*如果沒有找到，再從Host文件查找是否有該域名對應的IP
*如果沒有找到，再從路由器緩存找
*如果沒有找到，再從DNS緩存找
*如果都沒有找到，就從瀏覽器域名服務器向根域名服務器查找，沒有找到就繼續迭代，知道找到為止
2）瀏覽器獲得IP地址后，瀏覽器向服務器請求連接，發起三次握手
3）連接建立起來后，瀏覽器向服務器發送http請求
4）服務器接收到這個請求，並根據路徑參數映射到特定的請求處理器進行處理，並將視圖以及相應的結果返回給瀏覽器
5）瀏覽器解析並渲染視圖，若遇到對js，css文件以及靜態圖片資源的引用，重復上述步驟向服務器請求資源
6）瀏覽器根據請求到的資源，數據渲染頁面，最終向用戶呈現
1）TCP對應的應用層協議
*FTP：文件傳輸協議，21端口
*Telnet：遠程登陸協議，23端口
*SMTP：簡單郵件傳送協議，25端口
*POP3：和SMTP對應，POP3用於接收郵件，110端口
*HTTP：超文本傳輸協議，80端口
2）UDP對應的應用層協議
*DNS：域名解析協議，53端口
*SNMP：簡單網絡管理協議，161端口
*TFTP:簡單文件傳輸協議，69端口