我正在编写自己的客户端和服务器，它们实现了我自己的应用层协议。对于传输层，使用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()和net.Listen()，我只能使用127.0.0.1:4444。使用127.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有效载荷为[112 97 116 104]。
最简单的比较方法是HTTP。
一个http url可能看起来像http://example:1234/bar
http客户端理解该URL。HTTP客户端(在底层)仍然会建立一个标准的TCP连接来到达那里。
它通过抓取主机和端口部分来实现这一点，并且(暂时)丢弃其他所有内容。因此，在该阶段只使用example和1234。
TCP连接建立后，使用路径部分作为第一行发送。
TCP客户不知道网址,他们知道主机和端口。如何处理路径部分取决于。