1.為什麼http也需要加上籤發

1.加簽、驗籤的作用
  常見的http請求互動過程中，請求引數通過url或者request body等形式傳輸。
  但是由於http請求的開放性，使得請求引數很容易被攔截篡改。
  因此，需要對請求引數進行加簽，然後在請求接受方對請求引數進行驗籤，
  確保兩個簽名是一樣的，驗籤通過之後請求處理方就可以進行業務邏輯處理了。
  但是，加簽和驗籤只能解決請求傳輸過程中引數篡改的問題，
  並不能解決敏感引數傳輸的安全性問題。

2.加簽、驗籤的處理思路
  加簽和驗籤就是在請求傳送方將請求引數通過加密演算法生成一個sign值，
  放到請求引數裡；請求接收方收到請求後，
  使用同樣的方式對請求引數也進行加密得到一個sign值，
  只要兩個sign值相同，就說明引數沒有被篡改。

 
3.簽名引數sign生成的方法：
   第一步：將所以頭引數(注意時所有引數)，出去sign本身，以及值是空的引數，按引數鍵字母升序排序。
   第二步：然後把排序後的引數按引數1值1引數2值2......引數n值n
            (這裡的引數和值必須是傳輸引數的原始值，不能是經過處理的，
             如不能將"轉成"後再拼接)的方式拼接成一個字串。
   第三步：把分配給接入方的驗證金鑰key拼接在第2步得到的字串前面。
   第四步：在上一步得到的字串前面加上金鑰key(這裡的金鑰key是介面提供方分配給介面接入方的)，
           然後計算md5值，得到32位字串，然後轉成大寫,得到的字串作為sign的值放到請求引數裡。

  
例子：
  描述：
   現在假設需要傳輸的資料是:
       http:
 
//xxx.com/api/guest/rechargeNotify?p2=v2&p1=v1&method=cancel&p3=&pn=vn(實際情況最好是通過post方式傳送)
 步驟：
    1.拼接字串，首先去除值是空的引數p3，剩下p2=v2&p1=v1&method=cancel&pn=vn，
      然後按引數名字元升序排序得到字串：method=cancel&p1=v1&p2=v2&pn=vn。  
    2.然後做引數名和值的拼接，最後得到methodcancelp1v1p2v2pnvn。
    3
 
.在上面拼接得到的字串前面加上驗證金鑰key，假設是abc，得到新的字串abcmethodcancelp1v1p2v2pnvn。
    4.將上面得到的字串進行md5計算，假設得到的是abcdef，然後轉為大寫，得到ABCDEF這個值即為sign簽名值。
      最終產生的url應該如下：http://xxx.com/api/guest/rechargeNotify?p2=v2&p1=v1&method=cancel&p3=&pn=vn&sign=ABCDEF
    5.注意：計算md5之前請確保請求傳送方和接收方使用的字串編碼一致，比如統一使用utf-8編碼，如果編碼方式不一致則計算出來的簽名會校驗失敗。
  驗簽過程
     其實就是將請求url按照上述的規則進行同樣的操作，計算得到引數的簽名值，
     然後和引數中傳遞的sign值進行對比，如果一致則校驗通過，否則校驗不通過。

ps:個人覺得簽字的驗證方式有很多，http請求和https請求都可以靈活的使用演算法實現自己的籤驗方式，都是為了防止第三方的攔截和串改

2.捂手發生的協議層

過程：
  tcp三次握手的過程，accept發生在三次握手哪個階段？

  第一次握手：客戶端傳送syn包(syn=j)到伺服器。
  第二次握手：伺服器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也傳送一個ASK包（ask=k）。
  第三次握手：客戶端收到伺服器的SYN＋ACK包，向伺服器傳送確認包ACK(ack=k+1)。
  三次握手完成後，客戶端和伺服器就建立了tcp連線。這時可以呼叫accept函式獲得此連線

http請求回頭捂手過程

http和捂手可以說沒有關係。

http是應用層協議，它的任務是與伺服器交換資訊。

至於怎麼連到伺服器，怎麼保證資料正確，http不管。

事實上它總是假設資料是正確地傳輸的。

而tcp的任務是保證連線的可靠，包括防丟、防錯。

為了做到這些，在初次連線時要進行3次握手，以保證確實連線到了目標機器。

而連線上後具體傳送什麼資料，tcp是不管的。

別的應用層協議也能通過tcp進行，那麼這種協議在底層也進行3次握手。

在某些情況下，http可以不通過tcp實現，那就不需要3次握手。

比如，我做了一把遙控咖啡壺，遙控器和壺通過紅外直接連線，通過htcpcp（RFC2324定義的超文字咖啡壺控制協議）與咖啡壺互動。

字元直接調製到紅外上，此時htcpcp應用層下面直接是物理層，當然不存在3次握手了，連ip地址和mac地址也不存在。

補充評論：

HTTP屬於TCP/IP協議族，所以絕大多數情況下HTTP下面是TCP。

強行構造例外也不是絕對不行（比如我的茶壺），但這樣做是不實用的。

3.為什麼http請求還要加IP白名單

答問了解：
  問：TCP三次握手成功後，IP地址在網路連線和資料傳輸就不再需要？這個命題對嗎？
  問：我囉嗦一句，解釋一下，當兩臺主機建立TCP連線時，握手前通過IP在相應埠進行握手通訊，當握手成功後，他們之間的資料傳輸還依賴IP地址嗎？ 
  問：想說說我自己的想法，我認為，握手成功後就跟IP地址沒有關係了 
  答：TCP 的核心就是IP，連線成功，保持連線，還得靠IP呢！ 

學習來源：

//簽名

https://www.cnblogs.com/boothsun/p/7460105.html

//捂手過程

https://blog.csdn.net/cywosp/article/details/6724518

//解答為什麼http會有捂手

https://www.zhihu.com/question/67772889

https://www.zhihu.com/question/52991675

https://bbs.csdn.net/topics/397796542

//為什麼要加白名單

http://www.goubanjia.com/help/article-62.html

//捂手和ip的關係

https://bbs.csdn.net/topics/392291171