7层网络协议啊 下层的tcp？

完了，我也不知道，同一个tcp吧

这不是加个请求id回复id就对应上了

来自ChatGPT：

在客户端与服务端进行并发请求时，需要确保每个请求和响应都能准确匹配。通常使用唯一标识符（如请求ID）来实现这一点。以下是实现这种匹配的一般步骤：

生成唯一请求ID：每次发送请求时，生成一个唯一的请求ID。
在请求中包含请求ID：将该请求ID包含在请求的某个字段中（如HTTP请求头、查询参数或请求体）。
服务端返回时包含请求ID：服务端在响应中包含相同的请求ID。
客户端匹配请求和响应：客户端根据请求ID来匹配响应与请求。

答对了 能不能要我啊

说明你的招聘条件写的有问题，没有排除掉不符合要求的。

使用10个并发的话那就是10个不同的TCP链接
使用HTTP Pipelining的话，那就是按请求顺序收到响应的顺序。

主要看解决问题的思路，不要过于公式化，比如你这个问题，思路就是分配一个 请求 id 或者标记位
对应 http1.1 都是 tcp 短链接，这个 id 就是 tcp 源端口
对应 http2 长链接，虽然我没去具体了解，但是也能猜到肯定是分配了一个类似的 id，然后分发给各个请求

这题还挺开放的？并发同步？并发异步？同步应该考的是握手挥手，异步应该考的是幂等。要不就互动的时候，看别人的思路，往深了问。

一楼的，7层协议是osi组织制定的标准，但是实际工业界并没采用这个标准啊。工业界用的是tcp/ip 5层协议。

http是应用层协议，它的更低一层是建立在传输层tcp协议之上。（听说最新的http3.0出来了，是改用了udp，但不是主流）

10个同时并发请求会对应并发10个tcp连接。每个请求对应一个独立的tcp连接。在socket传输层就已经很好分清楚请求-响应对了，还要啥编号啊。单个tcp连接内，完全就已经可以根据tcp的seq序列号分清请求-响应信息了

linux 下的理念：众生介是文件。

那么，一个连接 对应一个文件描述符 十个并发相当于 同时打开了十个不同的txt文件。

回包对应的是哪个请求？ 对应txt文件名 就是请求体，文件内容就是回包。

楼主问题其实不太好接后招，后面可能随口问一下 2核处理器 怎么同时处理十个并发。一个端口怎么让 多个进程来帮忙处理请求。

现在不都是并发吗？难道过早客一次只能处理一个请求

TCP vs 10个包
TCP：1号包在吗？
包：在的！
TCP：X房间开着在，你去X房间，并记录。
包：领ID进房间

UDP vs 10个包
UDP：这么多傻包，直接丢出去，管他哪个房间能接收，不在我这里就行

某一个自己关注的知识点别人答不出来太正常了，我以前也试过，就算不是特别生僻，人家大佬也不知道答案。

最后自我总结:连大佬和普通技术人都区分不出来的问题没有意义...除非你就想找出那个刚好背到或者了解到这个知识点的人，然后不介意这个人可能其他基础烂的一批

设计师在想怎么设计更合理，泥瓦匠还在为怎么切一块砖纠结。

你去一家医院看十种病，挂十个号，错不了的。面试的意义是找到能给你解决问题的人，而不是考倒一片，找一个没倒的人。

反正这问题对我来说挺生僻的，毕竟 HTTP 这个协议挺简单可靠很少需要关注这种细节。

仔细想了一下，有趣的点是：
- HTTP 设计之初就很简单，就连 TCP 连接都是每次重新建立；通过下面一层 TCP 的端口设计就能一一对应，不存在这个问题
- HTTP/2 开始多路复用学习了流式，肯定是传输考虑了这一点，设计了唯一的标识符来确定（我不知道具体实现，去搜了一下叫做 stream id）

然后麻烦来了，现实生活中用的 HTTP 1.1 这样的协议，是有 keep-alive 头来保持 TCP 连接不断的。这玩意是怎么在不改变协议的情况下，复用了同一个 TCP 连接，还能区分哪个响应对应哪个请求的？

搜了一圈答案是，虽然复用了同一条 TCP，但 HTTP 1.1 的请求还是一个个排队阻塞的，上一个请求响应了下一个才能发出。和 HTTP/2 有本质区别。

了解这东西，与日常的业务开发有毛的关系
你这是 思维方式都错了

还是你的角度 刁钻啊

需要区分http的什么版本，在http1.1没有开启pipeline的情况下 都是以一个TCP链接吗，请求响应 请求响应不需要特殊标识，开启pipeline，请求和响应都是需要有次序的，因此这也就会导致队头阻塞。http2.0会有streamid这个概念，正因为有了streamid从而也解决了http1.1的队头阻塞问题，当然此时也只是解决了应用层的队头阻塞问题，还是会存在TCP的队头阻塞问题（http3.0解决）。

照你这么问，那我问你：同一台电脑，电源键连续按10次，最后会开机还是关机？