通過企業服務治理中心呼叫第三方介面差點造成http請求走私攻擊

http和tcp的關係

1、由七層網路模型來看，tcp位於傳輸層，而http位於應用層。

2、http是建立在TCP連線上的，在老版本的http中，一次http請求就會建立一次TCP連線，http請求完成之後會斷開tcp連線，也被稱為短連線，但是隨著網際網路的發展，短連線請求的方式開銷大，效率不高，所以在新版本的http中會複用一個tcp連線，減少了頻繁的TCP連線開啟和關閉帶來的消耗。

http報文格式

1、起始行

起到對報文進行描述的作用，位於報文的第一行，請求報文和響應報文的起始行格式有所不同，請求報文的起始行的格式一般為：<方法><請求路徑><版本>，響應報文的起始行格式一般為：<版本><狀態><原因短語>。

2、請求頭

首部是可有可無的，存在的情況下，起始行後面的就是首部資料，每個首部都有一個名字，有特定含義的約定好的首部，也可以進行自行定義，每一行由名字後面跟著一個冒號:  ，然後就是首部的值，就像鍵值對一樣的。比如一些常見的Content-Length（請求體資料長度），Content-Type（請求體資料型別），Connection（連結是否要關閉，如果為close，則表示關閉tcp連線，如果為Keep-Alive，則表示複用tcp連線）

3、請求體

請求體資料也是可有可無的，存在的情況下可以包含任務資料組成的資料塊，具體的型別和長度在請求頭中的Content-Length（請求體資料長度），Content-Type（請求體資料型別）這兩個體現出來。

網路請求走私

一般大型企業的網路架構，應用網路都是比較複雜，有時候從安全形度來看，各個環境需要隔離，但是業務需求往往又要要求打通各個隔離環境網路，以便實現資料傳輸，這時候使用的伺服器和代理伺服器往往也是雨露均沾，在這樣複雜的網路環境下使用不同的代理伺服器進行資料的傳輸，由於現在的伺服器對網路協議的實現程度不同，導致請求轉發的時候可能會造成資料的錯亂，而導致請求失敗，嚴重的話會產生安全風險。

血案

我們的應用和第三方的應用服務接入企業服務治理中心進行統一的API管理，對方的服務還用一個haproxy進行負載轉發。整體如下圖

在一個業務場景中，需要先呼叫一個get請求，然後再呼叫post請求來完成。

測試驗證上生產跑了一段時間之後，會發現每隔半小時會有一個請求失敗，經過抓包分析和review程式碼得出結果，由於get請求帶了請求體{}，一個空的json，請求的長度為2，但實際上是不需要的（程式碼用了治理中的封裝好的API，但是說明穩定老舊，維護不及時，方法說明不清晰，在呼叫get請求的時候，構建請求體資料的時候new了一個空的map物件放進去，其實可以為null的），有時候get請求的請求體資料會丟失掉，然後複用tcp連線，那麼這個get請求就會讀取 接下來的post請求體的 兩個字元，導致post請求資料不一致，從而失敗。好在加了失敗重試機制，從而保證了業務沒有收到影響。

原因：1、網路複雜，代理伺服器各不相同，2、治理中心沒有清晰的說明文件