我正在撰寫自己的客戶端和服務器，它們實作了我自己的應用程式級協議。傳輸層使用 TCP。對于互聯網層，使用 IPv4。TCP 標頭和 IPv4 標頭都不包含任何有關 URL 路徑的資訊。TCP 頭包含埠，IPv4 包含 IP 地址。誰應該包含路徑？
所以，考慮這個 URL - 127.0.0.1:4444/location-path。127.0.0.1應該是IPv4的一部分。4444應該是TCP的一部分。例如，在 Golang 中，使用標準net.Dial()and net.Listen()，我只能使用127.0.0.1:4444. 使用 of127.0.0.1:4444/location-path會拋出錯誤，這確實是意料之中的，因為它僅提供對 TCP/IP/域名決議的支持，而/location-path不是所有這三個的一部分。
- 那么，在客戶端和服務器端，我應該如何處理
/location-path客戶端可以將請求發送到不同位置而服務器可以為不同位置提供服務的方式？ - 每個應用程式協議都應該實作自己的邏輯來處理
/location-path?
根據RFC 1738：
url-path
The rest of the locator consists of data specific to the
scheme, and is known as the "url-path". It supplies the
details of how the specified resource can be accessed. Note
that the "/" between the host (or port) and the url-path is
NOT part of the url-path.
The url-path syntax depends on the scheme being used, as does the
manner in which it is interpreted.
那么，我可以實作我自己的規則url-path以及客戶端和服務器將如何解釋它？要傳輸它，我可以將它作為資料發送嗎？
例如，我可以定義我自己的應用程式級協議的規則proto——將放置url-path在 TCP 有效負載的前四個位元組？所以，proto://127.0.0.1:4444/path會變成127.0.0.1:4444帶有 TCP payload 的[112 97 116 104]。
uj5u.com熱心網友回復：
比較這一點的最簡單方法是 HTTP。
http url 可能類似于 http://example:1234/bar
http 客戶端理解該 URL。HTTP 客戶端將（在幕后）仍然建立一個標準的 TCP 連接來到達那里。
它通過獲取主機和埠部分并（暫時）丟棄其他所有內容來實作此目的。所以只在那個階段使用exampleand 1234。
TCP連接建立后，會使用路徑部分作為第一行發送。
TCP 客戶端不知道 URL，他們知道主機和埠。您如何處理路徑部分取決于您。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/318228.html
上一篇：為urlretrieve的第三個引數的可呼叫函式添加附加引數
下一篇：gov.uk是頂級域名還是域名？