URL 路径的概念仅在应用层级别支持？

Question

我正在编写自己的客户端和服务器，它们实现了我自己的应用程序级协议。对于传输层，使用 TCP。对于 Internet 层，使用 IPv4。 TCP header 和 IPv4 header 都不包含有关 URL 路径的任何信息。 TCP header 包含端口，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/domain 名称解析，而 /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]。

Answer 1

最简单的比较方法是 HTTP。

http url 可能类似于 http://example:1234/bar

http 客户端理解 URL。 HTTP 客户端（在后台）仍会建立标准的 TCP 连接以到达那里。

它通过获取主机和端口部分并（暂时）丢弃其他所有内容来实现。所以在那个阶段只使用 example 和 1234。

TCP连接建立后，会使用路径部分作为第一行发送。

TCP 客户端不知道 URLs，他们知道主机和端口。你对路径部分的处理取决于你.

URL 路径的概念仅在应用层级别支持？

Concept of URL path is supported only at application layer level?

http

url

network-protocols

url-scheme