別？理清網(wǎng)絡(luò)通信層級與選型)
后端開發(fā)做久了總會(huì)遇到一類提問方式Http、Socket、WebSocket、WebService(SOAP)到底有什么區(qū)別面試官喜歡問剛轉(zhuǎn)行的同事也喜歡問。表面上是四個(gè)名詞實(shí)際上它們處在網(wǎng)絡(luò)通信的不同層級混在一起聊永遠(yuǎn)理不清。這個(gè)問題的價(jià)值在于一旦你把層次理清楚很多實(shí)際報(bào)錯(cuò)、選型困惑、架構(gòu)設(shè)計(jì)問題都會(huì)迎刃而解。這篇內(nèi)容不打算寫成教科書而是從我這些年做接口對接、實(shí)時(shí)推送、企業(yè)系統(tǒng)集成的經(jīng)驗(yàn)出發(fā)把這幾個(gè)東西拆開講明白。你可能是后端、前端、運(yùn)維也可能剛接觸網(wǎng)絡(luò)編程被各種概念繞暈。只要跟著把層級搞懂再看手邊的業(yè)務(wù)場景基本就不會(huì)再用錯(cuò)工具了。1. 先認(rèn)清層級這四個(gè)詞根本不在一個(gè)平面上1.1 Http是應(yīng)用層協(xié)議本質(zhì)是“通信格式的約定”Http超文本傳輸協(xié)議最常見的用途就是網(wǎng)頁瀏覽和接口調(diào)用。它規(guī)定客戶端和服務(wù)端之間怎么發(fā)請求、怎么回響應(yīng)。一次典型的HTTP請求開頭是請求行比如GET /api/user HTTP/1.1然后跟著一堆Header再往后是請求體。服務(wù)端返回時(shí)同樣有狀態(tài)行、Header和響應(yīng)體。很多人把HTTP當(dāng)成“連接”這是第一個(gè)誤區(qū)。HTTP并不是連接它更像“寄信的格式”信封上怎么寫收件人、正文怎么排版都有約定。真正把數(shù)據(jù)從一個(gè)進(jìn)程搬到另一個(gè)進(jìn)程的是TCP連接。HTTP只是坐在這條傳輸通道上的一種應(yīng)用協(xié)議。順著這個(gè)思路HTTP幾個(gè)關(guān)鍵點(diǎn)就很好記了請求-響應(yīng)模型客戶端先開口服務(wù)端被動(dòng)回答。無狀態(tài)服務(wù)端不會(huì)默認(rèn)記住你是誰需要Cookie、Session或Token補(bǔ)狀態(tài)。基于TCPHTTP/1.1、HTTP/2都建立在TCP之上但TCP連接可以被多個(gè)HTTP請求復(fù)用這就是常說的HTTP連接復(fù)用。HTTPS是HTTPTLS加密內(nèi)容不透明但通信模型沒變。我遇到過不少項(xiàng)目一說“長連接”就以為用了HTTP長連接。實(shí)際上HTTP/1.1的Keep-Alive只是讓TCP連接不立刻斷開后續(xù)請求仍然是一問一答服務(wù)端依然不能主動(dòng)往瀏覽器推數(shù)據(jù)。想做到服務(wù)端主動(dòng)推就得看WebSocket。1.2 Socket是操作系統(tǒng)提供的傳輸通道編程接口而不是協(xié)議Socket這個(gè)詞在熱詞里出現(xiàn)頻率極高比如“socket網(wǎng)絡(luò)編程”“抓取socket數(shù)據(jù)包”“socket read timed out”。但先糾正一個(gè)概念Socket不是協(xié)議它是操作系統(tǒng)提供的一組網(wǎng)絡(luò)編程接口。這組接口包括socket()、bind()、listen()、connect()、accept()、send()、recv()。通過它們你可以在TCP或UDP之上收發(fā)數(shù)據(jù)。Socket處在傳輸層和應(yīng)用層的“門口”你自己寫代碼決定發(fā)送的字節(jié)流長什么樣。你可以用Socket來實(shí)現(xiàn)HTTP也可以實(shí)現(xiàn)WebSocket也可以做一套完全私有的協(xié)議。因此“Socket連接”這個(gè)說法嚴(yán)格講是“通過Socket建立的TCP連接”。如果面試官問Socket和HTTP的區(qū)別最正確的回答是Socket是編程接口HTTP是應(yīng)用層協(xié)議Socket可以承載HTTP也可以承載其他協(xié)議。使用原生Socket做項(xiàng)目時(shí)最容易踩的坑是“消息邊界”。TCP是字節(jié)流不像UDP一個(gè)包一個(gè)包那么清晰。Socket的recv()可能一次讀到半個(gè)消息也可能一次讀到好幾個(gè)消息。我在做網(wǎng)關(guān)采集時(shí)習(xí)慣在消息頭里加4字節(jié)長度字段接收端先收長度再收正文這個(gè)方案比用分隔符穩(wěn)定得多。抓包時(shí)看到一堆二進(jìn)制數(shù)據(jù)不要驚訝Socket本身不關(guān)心你發(fā)的是文字還是二進(jìn)制。1.3 WebService(SOAP)是一整套遠(yuǎn)程調(diào)用規(guī)范而不是某一個(gè)具體傳輸協(xié)議WebService這個(gè)名字聽起來像“網(wǎng)頁服務(wù)”但實(shí)際指遠(yuǎn)程服務(wù)調(diào)用。廣義上REST接口也能叫WebService但加上SOAP括號后基本特指SOAP協(xié)議那套玩法。SOAP簡單對象訪問協(xié)議的核心是用XML封裝請求和響應(yīng)通過WSDL描述服務(wù)契約然后跑在HTTP、SMTP甚至TCP之上。這意味著WebService(SOAP)并不和HTTP直接競爭它更像是“騎在HTTP背上的一頭大象”。HTTP負(fù)責(zé)傳輸SOAP負(fù)責(zé)把業(yè)務(wù)消息包成標(biāo)準(zhǔn)XML。理解了這個(gè)層次之后再回頭看他人的提問“Http、Socket、WebSocket、WebService(SOAP)之間的區(qū)別”就會(huì)發(fā)現(xiàn)這不是四個(gè)同級別選手的PK而是不同層級工具的交叉對比。接下來把最容易混淆的兩組拆開細(xì)說。2. WebSocket與Http的“反著來”使用姿勢2.1 為什么Http做不到實(shí)時(shí)推送WebSocket可以HTTP的設(shè)計(jì)初衷是“用戶從服務(wù)器拿東西”所以服務(wù)端天然不會(huì)主動(dòng)往客戶端發(fā)送數(shù)據(jù)。想實(shí)現(xiàn)實(shí)時(shí)推送早期方案是輪詢前端每隔兩三秒請求一次接口問“有新數(shù)據(jù)嗎”。數(shù)據(jù)量小、頻率低時(shí)還行一旦用戶量大或者數(shù)據(jù)變化頻繁服務(wù)器會(huì)被無效請求壓垮網(wǎng)絡(luò)開銷也大。長輪詢稍微好一點(diǎn)客戶端發(fā)起請求服務(wù)端沒有新數(shù)據(jù)就掛著不返回直到有數(shù)據(jù)再響應(yīng)然后客戶端立刻再發(fā)下一次請求。這種做法把“推送”做成了“延長的請求”但連接資源占用很高且仍然不是真正的雙向通信。WebSocket改變了這個(gè)模型。它是真正的全雙工協(xié)議一次握手成功后客戶端和服務(wù)端可以隨時(shí)發(fā)幀給對方。比如訂單狀態(tài)變化、大屏數(shù)據(jù)刷新、聊天消息這些都是WebSocket的典型場景。我之前做一個(gè)設(shè)備監(jiān)控項(xiàng)目后端用Python Django檢測到設(shè)備離線后需要立刻通知前端。如果用HTTP前端只能每秒輪詢頁面還在閃爍服務(wù)端負(fù)載還高。后來改成Django Channels WebSocket后臺有數(shù)據(jù)就往指定連接推前端頁面基本秒級更新負(fù)載也降下來了。關(guān)鍵點(diǎn)是WebSocket雖然名字里帶Socket但它是應(yīng)用層協(xié)議不是裸Socket編程。它反而依賴HTTP完成最初的握手。2.2 從Http升級到WebSocket握手過程藏著什么細(xì)節(jié)WebSocket和HTTP的關(guān)系最清晰的地方就是握手階段?？蛻舳税l(fā)起的仍然是一個(gè)普通HTTP GET請求但帶上了升級頭GET /chat HTTP/1.1 Host: example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ Sec-WebSocket-Version: 13服務(wù)端如果同意升級會(huì)返回101 Switching Protocols同時(shí)帶上Sec-WebSocket-Accept這是服務(wù)端根據(jù)Sec-WebSocket-Key加上固定GUID做SHA-1和Base64后的結(jié)果。從這之后雙方不再說HTTP開始說WebSocket幀。這里就引出一個(gè)很多初學(xué)者困惑的現(xiàn)象為什么用Socket抓包時(shí)WebSocket收到的數(shù)據(jù)看起來“奇數(shù)字節(jié)后面補(bǔ)一個(gè)隨機(jī)數(shù)”這不是隨機(jī)補(bǔ)位而是WebSocket規(guī)范規(guī)定的掩碼機(jī)制。客戶端發(fā)給服務(wù)端的幀必須用4字節(jié)的Masking-Key對有效載荷做異或處理。服務(wù)端收到幀后先讀出這4字節(jié)Key再異或還原出真實(shí)數(shù)據(jù)。所以從底層看數(shù)據(jù)中間確實(shí)會(huì)多出幾個(gè)“看似隨機(jī)”的字節(jié)。這主要是防止緩存中毒攻擊不是協(xié)議抽風(fēng)。當(dāng)年我第一次用原生Socket加WebSocket幀解析時(shí)被這個(gè)設(shè)定坑了一整晚。實(shí)際操作SpringBoot整合WebSocket時(shí)不需要自己解析幀框架已經(jīng)把這些細(xì)節(jié)藏掉了。常用的方式是實(shí)現(xiàn)WebSocketHandler或直接用ServerEndpoint(/ws/xxx)注解。但理解了幀結(jié)構(gòu)對于排查“數(shù)據(jù)亂碼”“長度不對”這類問題很有幫助。2.3 生產(chǎn)環(huán)境里WebSocket的四個(gè)“殺手級”細(xì)節(jié)第一個(gè)細(xì)節(jié)是心跳。WebSocket雖然是長連接但網(wǎng)絡(luò)設(shè)備如Nginx、防火墻通常有閑置超時(shí)。如果一段時(shí)間沒有數(shù)據(jù)包連接可能被悄悄斷開。穩(wěn)妥做法是讓客戶端每30秒到60秒發(fā)一次Ping幀或者業(yè)務(wù)層心跳消息服務(wù)端回Pong。網(wǎng)上很多“連接莫名斷開”的案例基本都是心跳沒做。第二個(gè)細(xì)節(jié)是斷線重連。不要在斷開后立刻無腦重連否則服務(wù)端一抖動(dòng)所有客戶端同時(shí)涌入直接把服務(wù)打掛。我建議用指數(shù)退避第一次等1秒第二次等2秒第四次等8秒最多等一兩分鐘。重連成功后先做增量同步把離線期間漏掉的消息補(bǔ)回來。第三個(gè)細(xì)節(jié)是跨域。有人問“Socket有跨域嗎”這其實(shí)混淆了Socket和WebSocket。原生Socket不受瀏覽器同源策略約束談不上跨域。WebSocket跑在瀏覽器里服務(wù)端必須校驗(yàn)請求中的Origin頭。如果沒有校驗(yàn)惡意網(wǎng)站可能讓你瀏覽器悄悄連上你的后端構(gòu)造跨站W(wǎng)ebSocket劫持。面試?yán)飭柊踩@也是一個(gè)高頻點(diǎn)。第四個(gè)細(xì)節(jié)是網(wǎng)關(guān)代理配置。Nginx默認(rèn)不轉(zhuǎn)發(fā)Upgrade頭導(dǎo)致WebSocket握手失敗常見表現(xiàn)就是502 Bad Gateway或連接一閃就斷開。配置里必須顯式加上location /ws/ { proxy_pass http://backend_server; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_read_timeout 3600s; proxy_send_timeout 3600s; }proxy_read_timeout也要調(diào)大否則Nginx默認(rèn)空閑60秒就斷開長連接。這類問題我排查過多次大部分不是后端代碼問題而是代理層沒理解“升級”這個(gè)動(dòng)作。3. WebService(SOAP)被低估的穩(wěn)定性和繞不開的成本3.1 SOAP信封、WSDL和強(qiáng)類型這到底是怎樣的一套SOAP的報(bào)文結(jié)構(gòu)非常規(guī)矩永遠(yuǎn)是Envelope信封包著Header頭和Body體。Header放認(rèn)證信息、事務(wù)ID、路由信息Body放真正的業(yè)務(wù)參數(shù)。一個(gè)典型請求長這樣?xml version1.0 encodingUTF-8? soap:Envelope xmlns:soaphttp://www.w3.org/2003/05/soap-envelope soap:Header auth:Token xmlns:authhttp://example.com/authabc123/auth:Token /soap:Header soap:Body getUserInfo xmlnshttp://example.com/user userId1001/userId /getUserInfo /soap:Body /soap:Envelope如果你在企業(yè)系統(tǒng)里對接過ERP、MES、銀行接口大概率見過類似結(jié)構(gòu)。SOAP服務(wù)通常還會(huì)提供一份WSDL文檔里面寫清楚了方法名、參數(shù)類型、返回值結(jié)構(gòu)。利用工具比如Java的wsimport、.NET的wsdl.exe可以直接生成強(qiáng)類型客戶端代碼。調(diào)用方不用手拼XML維護(hù)起來相對省心。熱詞里出現(xiàn)的“u9copenapi xml soap”“webservice mes”正是這類場景用友U9的OpenAPI有SOAP接口MES系統(tǒng)往ERP傳工單、報(bào)工、領(lǐng)料數(shù)據(jù)往往就靠SOAP協(xié)議。這種跨廠商、跨系統(tǒng)的集成場景SOAP的標(biāo)準(zhǔn)化優(yōu)勢很明顯。3.2 為什么互聯(lián)網(wǎng)公司反而少用SOAPSOAP穩(wěn)定、嚴(yán)謹(jǐn)?shù)鷥r(jià)也大。最大的問題是XML本身非?！皢隆薄Ｒ粭l用戶信息用JSON可能幾十字節(jié)換成SOAP加上信封、命名空間和XML標(biāo)簽輕松翻到幾百字節(jié)甚至1KB。在移動(dòng)網(wǎng)絡(luò)環(huán)境里這種體積浪費(fèi)很傷人。其次SOAP調(diào)試比REST麻煩。REST接口用瀏覽器、Postman、curl就能調(diào)試SOAP需要專門工具比如SoapUI或者手動(dòng)構(gòu)造XML。前后端聯(lián)調(diào)效率低App和小程序端解析XML也比較痛苦。還有一個(gè)心智成本SOAP的安全、事務(wù)標(biāo)準(zhǔn)很多比如WS-Security、WS-ReliableMessaging。這些是優(yōu)點(diǎn)但團(tuán)隊(duì)成員如果只熟悉HTTP很容易寫出一堆“形似SOAP、實(shí)質(zhì)亂拼XML”的代碼。真正的SOAP客戶端應(yīng)該由WSDL生成而不是拿字符串拼接。所以我的判斷很明確對外部互聯(lián)網(wǎng)用戶提供API首選RESTful JSON實(shí)時(shí)雙向通信用WebSocket企業(yè)內(nèi)網(wǎng)、跨公司、跨系統(tǒng)的正式集成如果對方明確給出WSDL老老實(shí)實(shí)走SOAP類WebService。3.3 SOAP與REST/WebSocket的選型賬本用一個(gè)簡單表格記錄我的經(jīng)驗(yàn)維度WebService(SOAP)REST(HTTP/JSON)WebSocket數(shù)據(jù)格式XML結(jié)構(gòu)化強(qiáng)JSON輕量文本或二進(jìn)制幀傳輸契約WSDL強(qiáng)契約OpenAPI/Swagger弱契約無固定契約自己定客戶端生成自動(dòng)生成代碼手寫或生成均可手寫實(shí)時(shí)性差差強(qiáng)安全標(biāo)準(zhǔn)WS-Security成熟HTTPS/OAuth為主Origin校驗(yàn)Token典型場景銀行、ERP、MES、稅務(wù)開放API、小程序、App聊天、監(jiān)控大屏、協(xié)同編輯在企業(yè)集成里SOAP多用于“兩個(gè)系統(tǒng)之間、人和代碼陌生”的正式場合。REST多用于“我提供一個(gè)API大家按JSON來對接”的開放場合。WebSocket多用于“服務(wù)端有數(shù)據(jù)要主動(dòng)告訴前端”的實(shí)時(shí)場合。我做物聯(lián)網(wǎng)項(xiàng)目時(shí)經(jīng)常是多種協(xié)議混用設(shè)備端用原生Socket上報(bào)數(shù)據(jù)后端通過HTTP/REST對第三方提供查詢接口前端實(shí)時(shí)狀態(tài)用WebSocket接收財(cái)務(wù)系統(tǒng)對接銀行時(shí)又走SOAP。不要把選型看成“只用其中一個(gè)”架構(gòu)越復(fù)雜幾者共存的概率越大。4. 一張對比表加一組排查清單讓選型不再猶豫4.1 五維對比Http、Socket、WebSocket、WebService(SOAP)把核心區(qū)別壓縮成一張表適合收藏后隨時(shí)查看對比項(xiàng)HttpSocket編程接口WebSocketWebService(SOAP)所處層級應(yīng)用層協(xié)議傳輸層之上的API應(yīng)用層協(xié)議應(yīng)用層協(xié)議族通信模型請求-響應(yīng)雙向字節(jié)流全雙工請求-響應(yīng)數(shù)據(jù)格式文本可承載JSON/XML自定義字節(jié)流文本幀/二進(jìn)制幀XML連接方式短連接或Keep-Alive復(fù)用面向連接(UDP無連接)長連接通?；贖TTP POST有沒有狀態(tài)無狀態(tài)有連接狀態(tài)有狀態(tài)可以擴(kuò)展事務(wù)狀態(tài)典型場景REST API、網(wǎng)頁私有協(xié)議、網(wǎng)關(guān)、游戲?qū)崟r(shí)推送、聊天企業(yè)系統(tǒng)集成、銀行注意把Socket放進(jìn)表里和HTTP對比其實(shí)是拿“接口”和“協(xié)議”比維度不完全相同。但正因?yàn)楹芏嗳诉@么混用才有必要放到一起理清楚。Socket是“你能用手直接摸到TCP/UDP”HTTP、WebSocket、SOAP是“你在Socket之上定義的交流規(guī)則”。4.2 按場景走三步選型決策路徑與其死記區(qū)別不如把選型看成三個(gè)問題。第一服務(wù)端是否需要主動(dòng)給客戶端發(fā)數(shù)據(jù)如果不需要普通HTTP/REST足夠。如果需要優(yōu)先WebSocket不要再糾結(jié)輪詢還是長輪詢。第二你是跨系統(tǒng)、跨企業(yè)對接還是自有系統(tǒng)間聯(lián)調(diào)如果對方是銀行、稅務(wù)、大型ERP且提供WSDL文件那基本就是SOAP。如果對方只是給一個(gè)JSON接口文檔那走REST。第三你需要控制底層傳輸行為嗎比如物聯(lián)網(wǎng)網(wǎng)關(guān)、嵌入式設(shè)備、游戲服務(wù)器用現(xiàn)成的HTTP太重那就直接用Socket定義私有協(xié)議。用STM32這類嵌入式設(shè)備時(shí)很多人也找HTTP庫但最輕量的方式永遠(yuǎn)是底層Socket最多套一層簡單的應(yīng)用協(xié)議。這里補(bǔ)充一個(gè)常見誤區(qū)不要因?yàn)閃ebSocket名字里帶Socket就把嵌入式設(shè)備通信也設(shè)計(jì)成WebSocket。WebSocket是瀏覽器和長連接場景的好工具但設(shè)備端如果資源緊張直接TCP二進(jìn)制協(xié)議更合適。4.3 高頻報(bào)錯(cuò)速查表Socket/WebSocket/SOAP問題一次說清最后分享幾個(gè)我實(shí)測過的高頻報(bào)錯(cuò)以及排查方向。報(bào)錯(cuò)信息大概率原因處理建議Cant connect to local MySQL server through socket /tmp/mysql.sock客戶端走默認(rèn)Unix Socket但MySQL服務(wù)沒在預(yù)期位置或有TCP模式連接時(shí)加-h 127.0.0.1 -P 3306走TCP或調(diào)整配置中的socket路徑j(luò)ava.sql.SQLException: IO 錯(cuò): socket read timed out連接池空閑連接被防火墻/網(wǎng)關(guān)斷開Socket超時(shí)時(shí)間太短調(diào)大socketTimeout連接池加validationQuery檢查網(wǎng)絡(luò)白名單bind: only one usage of each socket address端口被占用或服務(wù)重復(fù)啟動(dòng)Windows用netstat -anoLinux用lsof -i:端口找到占用進(jìn)程Unexpected status 502 Bad GatewayNginx轉(zhuǎn)發(fā)不到后端或WebSocket沒帶Upgrade頭檢查后端端口是否監(jiān)聽WebSocket場景補(bǔ)上Upgrade和Connection配置The specified HTTP method is not allowedSOAP或某些接口要求POST你用了GETSOAP接口普遍用POST不要拿瀏覽器地址欄調(diào)試第三方異步回調(diào)連不上對端只允許白名單IP或中間設(shè)備空閑超時(shí)斷開確認(rèn)網(wǎng)絡(luò)白名單回調(diào)服務(wù)做心跳或重試策略這些報(bào)錯(cuò)看似亂其實(shí)都指向同一個(gè)事實(shí)協(xié)議選對了但參數(shù)或環(huán)境沒配好。排查時(shí)先確認(rèn)“這條連接在哪一層斷的”再往下看配置。比如報(bào)socket read timed out先判斷是防火墻切的、連接池切的還是數(shù)據(jù)庫本身慢而不是一上來就改HTTP超時(shí)時(shí)間。我個(gè)人每次做技術(shù)選型都會(huì)先畫一條“數(shù)據(jù)從源頭到終端”的路徑每一步問一次這里是請求響應(yīng)還是主動(dòng)推送這里傳輸?shù)膬?nèi)容是JSON還是XML這里需要標(biāo)準(zhǔn)契約還是自由格式這樣一圈問下來答案往往會(huì)自己浮出來。網(wǎng)絡(luò)通信沒有一個(gè)萬能方案理解層級比背十個(gè)區(qū)別更有用。 HTTP、Socket、WebSocket、SOAP到底啥區(qū)別？理清網(wǎng)絡(luò)通信層級與選型
后端開發(fā)做久了總會(huì)遇到一類提問方式Http、Socket、WebSocket、WebService(SOAP)到底有什么區(qū)別面試官喜歡問剛轉(zhuǎn)行的同事也喜歡問。表面上是四個(gè)名詞實(shí)際上它們處在網(wǎng)絡(luò)通信的不同層級混在一起聊永遠(yuǎn)理不清。這個(gè)問題的價(jià)值在于一旦你把層次理清楚很多實(shí)際報(bào)錯(cuò)、選型困惑、架構(gòu)設(shè)計(jì)問題都會(huì)迎刃而解。這篇內(nèi)容不打算寫成教科書而是從我這些年做接口對接、實(shí)時(shí)推送、企業(yè)系統(tǒng)集成的經(jīng)驗(yàn)出發(fā)把這幾個(gè)東西拆開講明白。你可能是后端、前端、運(yùn)維也可能剛接觸網(wǎng)絡(luò)編程被各種概念繞暈。只要跟著把層級搞懂再看手邊的業(yè)務(wù)場景基本就不會(huì)再用錯(cuò)工具了。1. 先認(rèn)清層級這四個(gè)詞根本不在一個(gè)平面上1.1 Http是應(yīng)用層協(xié)議本質(zhì)是“通信格式的約定”Http超文本傳輸協(xié)議最常見的用途就是網(wǎng)頁瀏覽和接口調(diào)用。它規(guī)定客戶端和服務(wù)端之間怎么發(fā)請求、怎么回響應(yīng)。一次典型的HTTP請求開頭是請求行比如GET /api/user HTTP/1.1然后跟著一堆Header再往后是請求體。服務(wù)端返回時(shí)同樣有狀態(tài)行、Header和響應(yīng)體。很多人把HTTP當(dāng)成“連接”這是第一個(gè)誤區(qū)。HTTP并不是連接它更像“寄信的格式”信封上怎么寫收件人、正文怎么排版都有約定。真正把數(shù)據(jù)從一個(gè)進(jìn)程搬到另一個(gè)進(jìn)程的是TCP連接。HTTP只是坐在這條傳輸通道上的一種應(yīng)用協(xié)議。順著這個(gè)思路HTTP幾個(gè)關(guān)鍵點(diǎn)就很好記了請求-響應(yīng)模型客戶端先開口服務(wù)端被動(dòng)回答。無狀態(tài)服務(wù)端不會(huì)默認(rèn)記住你是誰需要Cookie、Session或Token補(bǔ)狀態(tài)。基于TCPHTTP/1.1、HTTP/2都建立在TCP之上但TCP連接可以被多個(gè)HTTP請求復(fù)用這就是常說的HTTP連接復(fù)用。HTTPS是HTTPTLS加密內(nèi)容不透明但通信模型沒變。我遇到過不少項(xiàng)目一說“長連接”就以為用了HTTP長連接。實(shí)際上HTTP/1.1的Keep-Alive只是讓TCP連接不立刻斷開后續(xù)請求仍然是一問一答服務(wù)端依然不能主動(dòng)往瀏覽器推數(shù)據(jù)。想做到服務(wù)端主動(dòng)推就得看WebSocket。1.2 Socket是操作系統(tǒng)提供的傳輸通道編程接口而不是協(xié)議Socket這個(gè)詞在熱詞里出現(xiàn)頻率極高比如“socket網(wǎng)絡(luò)編程”“抓取socket數(shù)據(jù)包”“socket read timed out”。但先糾正一個(gè)概念Socket不是協(xié)議它是操作系統(tǒng)提供的一組網(wǎng)絡(luò)編程接口。這組接口包括socket()、bind()、listen()、connect()、accept()、send()、recv()。通過它們你可以在TCP或UDP之上收發(fā)數(shù)據(jù)。Socket處在傳輸層和應(yīng)用層的“門口”你自己寫代碼決定發(fā)送的字節(jié)流長什么樣。你可以用Socket來實(shí)現(xiàn)HTTP也可以實(shí)現(xiàn)WebSocket也可以做一套完全私有的協(xié)議。因此“Socket連接”這個(gè)說法嚴(yán)格講是“通過Socket建立的TCP連接”。如果面試官問Socket和HTTP的區(qū)別最正確的回答是Socket是編程接口HTTP是應(yīng)用層協(xié)議Socket可以承載HTTP也可以承載其他協(xié)議。使用原生Socket做項(xiàng)目時(shí)最容易踩的坑是“消息邊界”。TCP是字節(jié)流不像UDP一個(gè)包一個(gè)包那么清晰。Socket的recv()可能一次讀到半個(gè)消息也可能一次讀到好幾個(gè)消息。我在做網(wǎng)關(guān)采集時(shí)習(xí)慣在消息頭里加4字節(jié)長度字段接收端先收長度再收正文這個(gè)方案比用分隔符穩(wěn)定得多。抓包時(shí)看到一堆二進(jìn)制數(shù)據(jù)不要驚訝Socket本身不關(guān)心你發(fā)的是文字還是二進(jìn)制。1.3 WebService(SOAP)是一整套遠(yuǎn)程調(diào)用規(guī)范而不是某一個(gè)具體傳輸協(xié)議WebService這個(gè)名字聽起來像“網(wǎng)頁服務(wù)”但實(shí)際指遠(yuǎn)程服務(wù)調(diào)用。廣義上REST接口也能叫WebService但加上SOAP括號后基本特指SOAP協(xié)議那套玩法。SOAP簡單對象訪問協(xié)議的核心是用XML封裝請求和響應(yīng)通過WSDL描述服務(wù)契約然后跑在HTTP、SMTP甚至TCP之上。這意味著WebService(SOAP)并不和HTTP直接競爭它更像是“騎在HTTP背上的一頭大象”。HTTP負(fù)責(zé)傳輸SOAP負(fù)責(zé)把業(yè)務(wù)消息包成標(biāo)準(zhǔn)XML。理解了這個(gè)層次之后再回頭看他人的提問“Http、Socket、WebSocket、WebService(SOAP)之間的區(qū)別”就會(huì)發(fā)現(xiàn)這不是四個(gè)同級別選手的PK而是不同層級工具的交叉對比。接下來把最容易混淆的兩組拆開細(xì)說。2. WebSocket與Http的“反著來”使用姿勢2.1 為什么Http做不到實(shí)時(shí)推送WebSocket可以HTTP的設(shè)計(jì)初衷是“用戶從服務(wù)器拿東西”所以服務(wù)端天然不會(huì)主動(dòng)往客戶端發(fā)送數(shù)據(jù)。想實(shí)現(xiàn)實(shí)時(shí)推送早期方案是輪詢前端每隔兩三秒請求一次接口問“有新數(shù)據(jù)嗎”。數(shù)據(jù)量小、頻率低時(shí)還行一旦用戶量大或者數(shù)據(jù)變化頻繁服務(wù)器會(huì)被無效請求壓垮網(wǎng)絡(luò)開銷也大。長輪詢稍微好一點(diǎn)客戶端發(fā)起請求服務(wù)端沒有新數(shù)據(jù)就掛著不返回直到有數(shù)據(jù)再響應(yīng)然后客戶端立刻再發(fā)下一次請求。這種做法把“推送”做成了“延長的請求”但連接資源占用很高且仍然不是真正的雙向通信。WebSocket改變了這個(gè)模型。它是真正的全雙工協(xié)議一次握手成功后客戶端和服務(wù)端可以隨時(shí)發(fā)幀給對方。比如訂單狀態(tài)變化、大屏數(shù)據(jù)刷新、聊天消息這些都是WebSocket的典型場景。我之前做一個(gè)設(shè)備監(jiān)控項(xiàng)目后端用Python Django檢測到設(shè)備離線后需要立刻通知前端。如果用HTTP前端只能每秒輪詢頁面還在閃爍服務(wù)端負(fù)載還高。后來改成Django Channels WebSocket后臺有數(shù)據(jù)就往指定連接推前端頁面基本秒級更新負(fù)載也降下來了。關(guān)鍵點(diǎn)是WebSocket雖然名字里帶Socket但它是應(yīng)用層協(xié)議不是裸Socket編程。它反而依賴HTTP完成最初的握手。2.2 從Http升級到WebSocket握手過程藏著什么細(xì)節(jié)WebSocket和HTTP的關(guān)系最清晰的地方就是握手階段?？蛻舳税l(fā)起的仍然是一個(gè)普通HTTP GET請求但帶上了升級頭GET /chat HTTP/1.1 Host: example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ Sec-WebSocket-Version: 13服務(wù)端如果同意升級會(huì)返回101 Switching Protocols同時(shí)帶上Sec-WebSocket-Accept這是服務(wù)端根據(jù)Sec-WebSocket-Key加上固定GUID做SHA-1和Base64后的結(jié)果。從這之后雙方不再說HTTP開始說WebSocket幀。這里就引出一個(gè)很多初學(xué)者困惑的現(xiàn)象為什么用Socket抓包時(shí)WebSocket收到的數(shù)據(jù)看起來“奇數(shù)字節(jié)后面補(bǔ)一個(gè)隨機(jī)數(shù)”這不是隨機(jī)補(bǔ)位而是WebSocket規(guī)范規(guī)定的掩碼機(jī)制。客戶端發(fā)給服務(wù)端的幀必須用4字節(jié)的Masking-Key對有效載荷做異或處理。服務(wù)端收到幀后先讀出這4字節(jié)Key再異或還原出真實(shí)數(shù)據(jù)。所以從底層看數(shù)據(jù)中間確實(shí)會(huì)多出幾個(gè)“看似隨機(jī)”的字節(jié)。這主要是防止緩存中毒攻擊不是協(xié)議抽風(fēng)。當(dāng)年我第一次用原生Socket加WebSocket幀解析時(shí)被這個(gè)設(shè)定坑了一整晚。實(shí)際操作SpringBoot整合WebSocket時(shí)不需要自己解析幀框架已經(jīng)把這些細(xì)節(jié)藏掉了。常用的方式是實(shí)現(xiàn)WebSocketHandler或直接用ServerEndpoint(/ws/xxx)注解。但理解了幀結(jié)構(gòu)對于排查“數(shù)據(jù)亂碼”“長度不對”這類問題很有幫助。2.3 生產(chǎn)環(huán)境里WebSocket的四個(gè)“殺手級”細(xì)節(jié)第一個(gè)細(xì)節(jié)是心跳。WebSocket雖然是長連接但網(wǎng)絡(luò)設(shè)備如Nginx、防火墻通常有閑置超時(shí)。如果一段時(shí)間沒有數(shù)據(jù)包連接可能被悄悄斷開。穩(wěn)妥做法是讓客戶端每30秒到60秒發(fā)一次Ping幀或者業(yè)務(wù)層心跳消息服務(wù)端回Pong。網(wǎng)上很多“連接莫名斷開”的案例基本都是心跳沒做。第二個(gè)細(xì)節(jié)是斷線重連。不要在斷開后立刻無腦重連否則服務(wù)端一抖動(dòng)所有客戶端同時(shí)涌入直接把服務(wù)打掛。我建議用指數(shù)退避第一次等1秒第二次等2秒第四次等8秒最多等一兩分鐘。重連成功后先做增量同步把離線期間漏掉的消息補(bǔ)回來。第三個(gè)細(xì)節(jié)是跨域。有人問“Socket有跨域嗎”這其實(shí)混淆了Socket和WebSocket。原生Socket不受瀏覽器同源策略約束談不上跨域。WebSocket跑在瀏覽器里服務(wù)端必須校驗(yàn)請求中的Origin頭。如果沒有校驗(yàn)惡意網(wǎng)站可能讓你瀏覽器悄悄連上你的后端構(gòu)造跨站W(wǎng)ebSocket劫持。面試?yán)飭柊踩@也是一個(gè)高頻點(diǎn)。第四個(gè)細(xì)節(jié)是網(wǎng)關(guān)代理配置。Nginx默認(rèn)不轉(zhuǎn)發(fā)Upgrade頭導(dǎo)致WebSocket握手失敗常見表現(xiàn)就是502 Bad Gateway或連接一閃就斷開。配置里必須顯式加上location /ws/ { proxy_pass http://backend_server; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_read_timeout 3600s; proxy_send_timeout 3600s; }proxy_read_timeout也要調(diào)大否則Nginx默認(rèn)空閑60秒就斷開長連接。這類問題我排查過多次大部分不是后端代碼問題而是代理層沒理解“升級”這個(gè)動(dòng)作。3. WebService(SOAP)被低估的穩(wěn)定性和繞不開的成本3.1 SOAP信封、WSDL和強(qiáng)類型這到底是怎樣的一套SOAP的報(bào)文結(jié)構(gòu)非常規(guī)矩永遠(yuǎn)是Envelope信封包著Header頭和Body體。Header放認(rèn)證信息、事務(wù)ID、路由信息Body放真正的業(yè)務(wù)參數(shù)。一個(gè)典型請求長這樣?xml version1.0 encodingUTF-8? soap:Envelope xmlns:soaphttp://www.w3.org/2003/05/soap-envelope soap:Header auth:Token xmlns:authhttp://example.com/authabc123/auth:Token /soap:Header soap:Body getUserInfo xmlnshttp://example.com/user userId1001/userId /getUserInfo /soap:Body /soap:Envelope如果你在企業(yè)系統(tǒng)里對接過ERP、MES、銀行接口大概率見過類似結(jié)構(gòu)。SOAP服務(wù)通常還會(huì)提供一份WSDL文檔里面寫清楚了方法名、參數(shù)類型、返回值結(jié)構(gòu)。利用工具比如Java的wsimport、.NET的wsdl.exe可以直接生成強(qiáng)類型客戶端代碼。調(diào)用方不用手拼XML維護(hù)起來相對省心。熱詞里出現(xiàn)的“u9copenapi xml soap”“webservice mes”正是這類場景用友U9的OpenAPI有SOAP接口MES系統(tǒng)往ERP傳工單、報(bào)工、領(lǐng)料數(shù)據(jù)往往就靠SOAP協(xié)議。這種跨廠商、跨系統(tǒng)的集成場景SOAP的標(biāo)準(zhǔn)化優(yōu)勢很明顯。3.2 為什么互聯(lián)網(wǎng)公司反而少用SOAPSOAP穩(wěn)定、嚴(yán)謹(jǐn)?shù)鷥r(jià)也大。最大的問題是XML本身非?！皢隆薄Ｒ粭l用戶信息用JSON可能幾十字節(jié)換成SOAP加上信封、命名空間和XML標(biāo)簽輕松翻到幾百字節(jié)甚至1KB。在移動(dòng)網(wǎng)絡(luò)環(huán)境里這種體積浪費(fèi)很傷人。其次SOAP調(diào)試比REST麻煩。REST接口用瀏覽器、Postman、curl就能調(diào)試SOAP需要專門工具比如SoapUI或者手動(dòng)構(gòu)造XML。前后端聯(lián)調(diào)效率低App和小程序端解析XML也比較痛苦。還有一個(gè)心智成本SOAP的安全、事務(wù)標(biāo)準(zhǔn)很多比如WS-Security、WS-ReliableMessaging。這些是優(yōu)點(diǎn)但團(tuán)隊(duì)成員如果只熟悉HTTP很容易寫出一堆“形似SOAP、實(shí)質(zhì)亂拼XML”的代碼。真正的SOAP客戶端應(yīng)該由WSDL生成而不是拿字符串拼接。所以我的判斷很明確對外部互聯(lián)網(wǎng)用戶提供API首選RESTful JSON實(shí)時(shí)雙向通信用WebSocket企業(yè)內(nèi)網(wǎng)、跨公司、跨系統(tǒng)的正式集成如果對方明確給出WSDL老老實(shí)實(shí)走SOAP類WebService。3.3 SOAP與REST/WebSocket的選型賬本用一個(gè)簡單表格記錄我的經(jīng)驗(yàn)維度WebService(SOAP)REST(HTTP/JSON)WebSocket數(shù)據(jù)格式XML結(jié)構(gòu)化強(qiáng)JSON輕量文本或二進(jìn)制幀傳輸契約WSDL強(qiáng)契約OpenAPI/Swagger弱契約無固定契約自己定客戶端生成自動(dòng)生成代碼手寫或生成均可手寫實(shí)時(shí)性差差強(qiáng)安全標(biāo)準(zhǔn)WS-Security成熟HTTPS/OAuth為主Origin校驗(yàn)Token典型場景銀行、ERP、MES、稅務(wù)開放API、小程序、App聊天、監(jiān)控大屏、協(xié)同編輯在企業(yè)集成里SOAP多用于“兩個(gè)系統(tǒng)之間、人和代碼陌生”的正式場合。REST多用于“我提供一個(gè)API大家按JSON來對接”的開放場合。WebSocket多用于“服務(wù)端有數(shù)據(jù)要主動(dòng)告訴前端”的實(shí)時(shí)場合。我做物聯(lián)網(wǎng)項(xiàng)目時(shí)經(jīng)常是多種協(xié)議混用設(shè)備端用原生Socket上報(bào)數(shù)據(jù)后端通過HTTP/REST對第三方提供查詢接口前端實(shí)時(shí)狀態(tài)用WebSocket接收財(cái)務(wù)系統(tǒng)對接銀行時(shí)又走SOAP。不要把選型看成“只用其中一個(gè)”架構(gòu)越復(fù)雜幾者共存的概率越大。4. 一張對比表加一組排查清單讓選型不再猶豫4.1 五維對比Http、Socket、WebSocket、WebService(SOAP)把核心區(qū)別壓縮成一張表適合收藏后隨時(shí)查看對比項(xiàng)HttpSocket編程接口WebSocketWebService(SOAP)所處層級應(yīng)用層協(xié)議傳輸層之上的API應(yīng)用層協(xié)議應(yīng)用層協(xié)議族通信模型請求-響應(yīng)雙向字節(jié)流全雙工請求-響應(yīng)數(shù)據(jù)格式文本可承載JSON/XML自定義字節(jié)流文本幀/二進(jìn)制幀XML連接方式短連接或Keep-Alive復(fù)用面向連接(UDP無連接)長連接通?；贖TTP POST有沒有狀態(tài)無狀態(tài)有連接狀態(tài)有狀態(tài)可以擴(kuò)展事務(wù)狀態(tài)典型場景REST API、網(wǎng)頁私有協(xié)議、網(wǎng)關(guān)、游戲?qū)崟r(shí)推送、聊天企業(yè)系統(tǒng)集成、銀行注意把Socket放進(jìn)表里和HTTP對比其實(shí)是拿“接口”和“協(xié)議”比維度不完全相同。但正因?yàn)楹芏嗳诉@么混用才有必要放到一起理清楚。Socket是“你能用手直接摸到TCP/UDP”HTTP、WebSocket、SOAP是“你在Socket之上定義的交流規(guī)則”。4.2 按場景走三步選型決策路徑與其死記區(qū)別不如把選型看成三個(gè)問題。第一服務(wù)端是否需要主動(dòng)給客戶端發(fā)數(shù)據(jù)如果不需要普通HTTP/REST足夠。如果需要優(yōu)先WebSocket不要再糾結(jié)輪詢還是長輪詢。第二你是跨系統(tǒng)、跨企業(yè)對接還是自有系統(tǒng)間聯(lián)調(diào)如果對方是銀行、稅務(wù)、大型ERP且提供WSDL文件那基本就是SOAP。如果對方只是給一個(gè)JSON接口文檔那走REST。第三你需要控制底層傳輸行為嗎比如物聯(lián)網(wǎng)網(wǎng)關(guān)、嵌入式設(shè)備、游戲服務(wù)器用現(xiàn)成的HTTP太重那就直接用Socket定義私有協(xié)議。用STM32這類嵌入式設(shè)備時(shí)很多人也找HTTP庫但最輕量的方式永遠(yuǎn)是底層Socket最多套一層簡單的應(yīng)用協(xié)議。這里補(bǔ)充一個(gè)常見誤區(qū)不要因?yàn)閃ebSocket名字里帶Socket就把嵌入式設(shè)備通信也設(shè)計(jì)成WebSocket。WebSocket是瀏覽器和長連接場景的好工具但設(shè)備端如果資源緊張直接TCP二進(jìn)制協(xié)議更合適。4.3 高頻報(bào)錯(cuò)速查表Socket/WebSocket/SOAP問題一次說清最后分享幾個(gè)我實(shí)測過的高頻報(bào)錯(cuò)以及排查方向。報(bào)錯(cuò)信息大概率原因處理建議Cant connect to local MySQL server through socket /tmp/mysql.sock客戶端走默認(rèn)Unix Socket但MySQL服務(wù)沒在預(yù)期位置或有TCP模式連接時(shí)加-h 127.0.0.1 -P 3306走TCP或調(diào)整配置中的socket路徑j(luò)ava.sql.SQLException: IO 錯(cuò): socket read timed out連接池空閑連接被防火墻/網(wǎng)關(guān)斷開Socket超時(shí)時(shí)間太短調(diào)大socketTimeout連接池加validationQuery檢查網(wǎng)絡(luò)白名單bind: only one usage of each socket address端口被占用或服務(wù)重復(fù)啟動(dòng)Windows用netstat -anoLinux用lsof -i:端口找到占用進(jìn)程Unexpected status 502 Bad GatewayNginx轉(zhuǎn)發(fā)不到后端或WebSocket沒帶Upgrade頭檢查后端端口是否監(jiān)聽WebSocket場景補(bǔ)上Upgrade和Connection配置The specified HTTP method is not allowedSOAP或某些接口要求POST你用了GETSOAP接口普遍用POST不要拿瀏覽器地址欄調(diào)試第三方異步回調(diào)連不上對端只允許白名單IP或中間設(shè)備空閑超時(shí)斷開確認(rèn)網(wǎng)絡(luò)白名單回調(diào)服務(wù)做心跳或重試策略這些報(bào)錯(cuò)看似亂其實(shí)都指向同一個(gè)事實(shí)協(xié)議選對了但參數(shù)或環(huán)境沒配好。排查時(shí)先確認(rèn)“這條連接在哪一層斷的”再往下看配置。比如報(bào)socket read timed out先判斷是防火墻切的、連接池切的還是數(shù)據(jù)庫本身慢而不是一上來就改HTTP超時(shí)時(shí)間。我個(gè)人每次做技術(shù)選型都會(huì)先畫一條“數(shù)據(jù)從源頭到終端”的路徑每一步問一次這里是請求響應(yīng)還是主動(dòng)推送這里傳輸?shù)膬?nèi)容是JSON還是XML這里需要標(biāo)準(zhǔn)契約還是自由格式這樣一圈問下來答案往往會(huì)自己浮出來。網(wǎng)絡(luò)通信沒有一個(gè)萬能方案理解層級比背十個(gè)區(qū)別更有用。