Google为每个收到的请求打开多少个套接字? [英] How many sockets do Google open for every request it receives?

问题描述

以下是我最近在一家知名网络软件公司的采访经历.有人问我有关互连TCP级别和Web请求的问题，这让我很困惑.我真的很想知道专家对答案的看法.这不仅涉及访谈，还涉及对网络工作原理(或应用层和传输层如何进行交互，如果有的话)的基本理解.

The following is my recent interview experience with a reputed network software company. I was asked questions about interconnecting TCP level and web requests and that confused me a lot. I really would like to know expert opinions on the answers. It is not just about the interview but also about a fundamental understanding of how networking work (or how application layer and transport layer cross-talk, if at all they do).

1. 采访者:告诉我幕后发生的过程 我打开浏览器，然后在其中输入google.com.

1. Interviewer: Tell me the process that happens behind the scenes when I open a browser and type google.com in it.

Me :发生的第一件事是创建了一个套接字 由{SRC-IP, SRC-PORT, DEST-IP, DEST-PORT, PROTOCOL}标识.这 SRC-PORT number是浏览器给出的随机数.通常是TCP/IP 连接协议(建立三向握手).现在 客户端(我的浏览器)和服务器(Google)都准备好处理 要求. (已建立TCP连接).

Me: The first thing that happens is a socket is created which is identified by {SRC-IP, SRC-PORT, DEST-IP, DEST-PORT, PROTOCOL}. The SRC-PORT number is a random number given by the browser. Usually the TCP/IP connection protocol (three-way handshake is established). Now both the client (my browser) and the server (Google) are ready to handle requests. (TCP connection is established).

采访者:等一下，何时解析名称?

Interviewer: Wait, when does the name resolution happen?

我:是的，很抱歉.它甚至应该在创建套接字之前发生. DNS名称解析首先发生，以获取Google的IP地址. 到达.

Me: Yep, I am sorry. It should have happened before even the socket is created. DNS name resolve happens first to get the IP address of Google to reach at.

访问器:是否创建了用于DNS名称解析的套接字?

Interviewer: Is a socket created for DNS name resolution?

我:嗯，我实际上不知道.但是我所知道的DNS名称解析是 无连接.也就是说，它不是TCP，而是UDP.只有一个 请求-响应周期发生. (因此，为DNS创建了一个新的套接字 名称解析).

Me: hmm, I actually do not know. But all I know DNS name resolution is connectionless. That is, it's not TCP but UDP. Only a single request-response cycle happens. (So there is a new socket created for DNS name resolution).

采访者:google.com已打开，可以接受来自其他人的其他请求 客户.建立与Google屏蔽的联系也是如此 其他用户?

Interviewer: google.com is open for other requests from other clients. So is establishing your connection with Google blocking other users?

我:我不确定Google如何处理这个问题.但是在典型的插座中 交流，它在最小程度上受阻.

Me: I am not sure how Google handles this. But in a typical socket communication, it is blocking to a minimal extent.

采访者:您认为如何处理?

Interviewer: How do you think this can be handled?

Me :我猜该进程派生了一个新线程并创建了一个套接字来处理我的 要求.从现在开始，我与之通信的套接字端点 Google是这个子套接字.

Me: I guess the process forks a new thread and creates a socket to handle my request. From now on, my socket endpoint of communication with Google is this child socket.

访问者:如果是这种情况，则此子套接字的端口号是 与父母不同?

Interviewer: If that is the case, is this child socket’s port number different than the parent one?

Me :父套接字正在80侦听来自的新请求 客户.该孩子必须在其他端口号上监听.

Me: The parent socket is listening at 80 for new requests from clients. The child must be listening at a different port number.

访问器:自目标端口号更改以来，如何维护TCP连接. (这是Google数据包上发送的src端口号)吗?

Interviewer: How is your TCP connection maintained since your destination port number has changed. (That is the src-port number sent on Google's packet) ?

我:我作为客户端看到的目标端口始终为80. 响应也被发送回，它也来自端口80.我猜是OS/the 父进程将源端口设置回80，然后再将其发送回 帖子.

Me: The dest-port that I see as a client is always 80. When a response is sent back, it also comes from port 80. I guess the OS/the parent process sets the source port back to 80 before it sends back the post.

Interviewer :您的套接字连接建立了多长时间 谷歌?

Interviewer: How long is your socket connection established with Google?

我:如果我一段时间未提出任何要求， 主线程关闭其子套接字，并随后发出来自其的任何后续请求 我会像我是新客户一样.

Me: If I don’t make any requests for a period of time, the main thread closes its child socket and any subsequent requests from me will be like I am a new client.

Interviewer :不，Google不会保留专用的子套接字用于 你.它可以处理您的请求并正确丢弃/回收套接字 离开.

Interviewer: No, Google will not keep a dedicated child socket for you. It handles your request and discards/recycles the sockets right away.

采访者:尽管Google可能有很多服务器要提供服务 请求时，每个服务器只能在端口80上打开一个父套接字.访问Google网页的客户端数量必须大于其所拥有的服务器数量.通常如何处理?

Interviewer: Although Google may have many servers to serve requests, each server can have only one parent socket opened at port 80. The number of clients to access Google's webpage must be larger than the number of servers they have. How is this usually handled?

我:我不确定如何处理.我看到了唯一的办法 工作是为收到的每个请求生成一个线程.

Me: I am not sure how this is handled. I see the only way it could work is spawn a thread for each request it receives.

采访者:您认为Google处理此问题的方式与 任何银行网站?

Interviewer: Do you think the way Google handles this is different from any bank website?

Me :在TCP-IP套接字级别，它应该是 相似的.在请求级别，由于会话不同而略有不同 保持状态，以保持请求银行网站之间的状态.

Me: At the TCP-IP socket level, it should be similar. At the request level, slightly different because a session is maintained to keep state between requests for banks' websites.

如果有人可以解释每一个要点，这将对许多初学者产生很大的帮助.

If someone can give an explanation of each of the points, it will be very helpful for many beginners in networking.

推荐答案

Google为每个收到的请求打开多少个套接字?

How many sockets do Google open for every request it receives?

这个问题实际上没有出现在面试中，但是它在您的标题中，所以我会回答. Google根本不打开任何套接字.您的浏览器可以做到这一点. Google以新套接字的形式接受连接，但我不会将其描述为打开"它们.

This question doesn't actually appear in the interview, but it's in your title so I'll answer it. Google doesn't open any sockets at all. Your browser does that. Google accepts connections, in the form of new sockets, but I wouldn't describe that as 'opening' them.

采访者:告诉我打开浏览器并在其中输入google.com时在后台发生的过程.

Interviewer : Tell me the process that happens behind the scene when I open a browser and type google.com in it.

我:首先发生的是创建了一个套接字，该套接字由{SRC-IP，SRC-PORT，DEST-IP，DEST-PORT，PROTOCOL}标识.

Me : The first thing that happens is a socket is created which is identified by {SRC-IP, SRC-PORT, DEST-IP, DEST-PORT, PROTOCOL}.

不. 连接由元组标识.套接字是连接的端点.

No. The connection is identified by the tuple. The socket is an endpoint to the connection.

SRC-PORT号是浏览器提供的随机数.

The SRC-PORT number is a random number given by browser.

不.通过操作系统.

通常是TCP/IP连接协议(建立三种方式的握手).现在，客户端(我的浏览器)和服务器(谷歌)都可以处理请求了. (已建立TCP连接)

Usually TCP/IP connection protocol (three way handshake is established). Now the both client (my browser) and server (google) are ready to handle requests. (TCP connection is established)

采访者:等等，什么时候解析名字?

Interviewer: wait, when does the name resolution happens?

我:是的，很抱歉.它甚至应该在创建套接字之前发生. DNS名称解析首先发生，以获取google的IP地址.

Me: yep, I am sorry. It should have happened before even the socket is created. DNS name resolve happens first to get the IP address of google to reach at.

访查员:是否为DNS名称解析创建了套接字?

Interviewer : Is a socket created for DNS name resolution?

我:嗯，实际上不知道.但是我所知道的DNS名称解析是一种无连接的方法.那不是TCP，而是UDP.仅发生单个请求-响应周期. (因此，还会创建一个用于DNS名称解析的新套接字.)

Me : hmm, Iactually do not know. But all I know DNS name resolution is a connection-less. That is it not TCP but UDP. only a single request-response cycle happens. (so is a new socket created for DNS name resolution).

任何合理实现的浏览器都会将整个内容委派给操作系统的Sockets库，该库的内部功能取决于操作系统.在转到DNS服务器之前，它可能会查看内存中的高速缓存，文件，数据库，LDAP服务器等几项内容，这可以通过TCP或UDP完成.这不是一个好问题.

Any rationally implemented browser would delegate the entire thing to the operating system's Sockets library, whose internal functioning depends on the OS. It might look at an in-memory cache, a file, a database, an LDAP server, several things, before going out to a DNS server, which it can do via either TCP or UDP. It's not a great question.

访问者:google.com已打开，可以接受来自其他客户端的其他请求.那么建立您与Google的联系是否会阻止其他用户?

Interviewer: google.com is open for other requests from other clients. so is establishing you connection with google is blocking other users?

我:我不确定Google如何处理此问题.但是在典型的套接字通信中，它的阻塞程度很小.

Me: I am not sure how google handles this. But in a typical socket communication, it is blocking to a minimal extent.

又错了.具体来说，它与Google无关.一个TCP服务器在每个接受的连接中都有一个单独的套接字，任何经过合理构造的TCP服务器都可以通过多线程，多路复用/非阻塞I/O或异步I/O完全独立地处理它们.他们不会互相阻挡.

Wrong again. It has very little to do with Google specifically. A TCP server has a separate socket per accepted connection, and any rationally constructed TCP server handles them completely independently, either via multithreading, muliplexed/non-blocking I/O, or asynchronous I/O. They don't block each other.

采访者:您如何看待这件事?

Interviewer : How do you think this can be handled?

我:我猜该进程派生了一个新线程并创建了一个套接字来处理我的请求.从现在开始，我与Google通信的套接字端点就是这个子套接字.

Me : I guess the process forks a new thread and creates a socket to handle my request. From now on, my socket endpoint of communication with google is this this child socket.

创建线程，而不是分叉"线程.派生一个进程将创建另一个进程，而不是另一个线程.套接字没有被创建"到可以接受的程度，通常在线程创建之前.它不是子"套接字.

Threads are created, not 'forked'. Forking a process creates another process, not another thread. The socket isn't 'created' so much as accepted, and this would normally precede thread creation. It isn't a 'child' socket.

访问者:如果是这种情况，那么此子套接字的端口号是否与父套接字的端口号不同??

Interviewer: If that is the case, is this child socket’s port number different than the parent one.?

我:父套接字正在80侦听来自客户端的新请求.孩子必须在其他端口号上监听.

Me: The parent socket is listening at 80 for new requests from clients. The child must be listening at a different port number.

又错了.接受的套接字使用与侦听套接字相同的端口号，并且接受的套接字根本不监听"，它是正在接收和发送.

Wrong again. The accepted socket uses the same port number as the listening socket, and the accepted socket isn't 'listening' at all, it is receiving and sending.

访查员:自从目标端口号更改以来，如何保持TCP连接. (这是在Google数据包上发送的src端口号)吗?

Interviewer: how is your TCP connection maintained since your Dest-port number has changed. (That is the src-port number sent on google's packet) ?

我:我在客户端看到的dest-port始终是80.发送回请求时，它也来自端口80.我猜OS/父进程会在发送之前将src端口设置回80.返回帖子.

Me: The dest-port as what I see as client is always 80. when request is sent back, it also comes from port 80. I guess the OS/the parent process sets the src port back to 80 before it sends back the post.

该问题旨在探索您以前的错误答案.您继续输入错误答案仍然是错误的.

This question was designed to explore your previous wrong answer. Your continuation of your wrong answer is still wrong.

Interviewer:您与Google建立的套接字连接多长时间了?

Interviewer : how long is your socket connection established with google?

我:如果我在一段时间内未发出任何请求，则主线程将关闭其子套接字，并且随后来自我的任何请求都将像是新客户端一样.

Me : If I don’t make any requests for a period of time, the main thread closes its child socket and any subsequent requests from me will be like am a new client.

又错了.您对Google的线程一无所知，更不用说哪个线程关闭了套接字.任何一端都可以随时关闭连接.服务器端很可能会击败您，但是它不是一成不变的，如果有任何线程可以做到，也不会.

Wrong again. You don't know anything about threads at Google, let alone which thread closes the socket. Either end can close the connection at any time. Most probably the server end will beat you to it, but it isn't set in stone, and neither is which if any thread will do it.

面试官:不，谷歌不会为您保留专用的子套接字.它可以处理您的请求并立即丢弃/回收套接字.

Interviewer : No, google will not keep a dedicated child socket for you. It handles your request and discards/recycles the sockets right away.

访问者 在这里是错误的.他似乎没有听说过HTTP keep-alive，也没有听说过HTTP 1.1的默认设置.

Here the interviewer is wrong. He doesn't seem to have heard of HTTP keep-alive, or the fact that it is the default in HTTP 1.1.

访问者:尽管google可能有许多服务器可以处理请求，但每台服务器只能在端口80上打开一个父套接字.访问google网页的客户端数量必须超过其所拥有的服务器数量.通常如何处理?

Interviewer: Although google may have many servers to serve requests, each server can have only one parent socket opened at port 80. The number of clients to access google webpage must be exceeding larger than the number of servers they have. How is this usually handled?

我:我不确定如何处理.我看到唯一可行的方法是为收到的每个请求生成一个线程.

Me : I am not sure how this is handled. I see the only way it could work is spawn a thread for each request it receives.

在这里您根本没有回答问题.他正在寻找有关负载平衡器或轮询DNS或所有这些服务器前面的内容的答案.但是，他和他的句子访问Google网页的客户端数量必须超过其拥有的服务器数量"之类的说法已经被你们都错误地称为子套接字"的存在所回答.同样，这不是一个大问题，除非您未正确报告.

Here you haven't answered the question at all. He is fishing for an answer about load-balancers or round-robin DNS or something in front of all those servers. However his sentence "the number of clients to access google webpage must be exceeding larger than the number of servers they have" has already been answered by the existence of what you are both incorrectly calling 'child sockets'. Again, not a great question, unless you've reported it inaccurately.

采访者:您认为Google处理的方式与任何银行网站都不同吗?

Interviewer : Do you think the way Google handles is different from any bank website?

我:在TCP-IP套接字级别，它应该是相似的.在请求级别，由于保持会话以保持Banks网站中请求之间的状态而略有不同.

Me: At the TCP-IP socket level, it should be similar. At the request level, slightly different because a session is maintained to keep state between requests in Banks websites.

您几乎正确地做到了这一点.存在与Google以及银行网站的HTTP会话.这不是什么问题.他应该问的是事实，而不是您的观点.

You almost got this one right. HTTP sessions to Google exist, as well as to bank websites. It isn't much of a question. He should be asking for facts, not your opinion.

总体而言，(a)您完全没有通过面试，并且(b)您沉迷于 far 太多的猜测.您应该只说我不知道"，然后让面试继续进行您确实了解的事情.

Overall, (a) you failed the interview completely, and (b) you indulged in far too much guesswork. You should have simply stated 'I don't know' and let the interview proceed to things that you do know about.

这篇关于Google为每个收到的请求打开多少个套接字?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！