bra*_*orm 11 sockets port networking tcp request
以下是我最近与知名网络软件公司的面试经历.我被问到有关互连TCP级别和Web请求的问题,这让我很困惑.我真的很想知道答案的专家意见.它不仅涉及面试,还涉及对网络如何工作的基本理解(或者应用层和传输层如何交叉,如果他们这样做的话).
采访者:告诉我打开浏览器并输入内容后幕后发生的过程google.com.
我:首先发生的是创建一个套接字,由...标识{SRC-IP, SRC-PORT, DEST-IP, DEST-PORT, PROTOCOL}.该
SRC-PORT数字是浏览器给出的随机数.通常是TCP/IP连接协议(建立三次握手).现在,客户端(我的浏览器)和服务器(Google)都准备好处理请求.(建立TCP连接).
采访者:等一下,名称解析何时发生？
我:是的,对不起.它应该在创建套接字之前发生.DNS名称解析首先发生以获取Google的IP地址.
访问者:是否为DNS名称解析创建了一个套接字？
我:嗯,我实际上不知道.但我所知道的DNS名称解析是无连接的.也就是说,它不是TCP而是UDP.只发生一个请求 - 响应周期.(因此,为DNS名称解析创建了一个新的套接字).
采访者:google.com对其他客户的其他请求开放.那么与谷歌建立联系阻止其他用户呢？
我:我不确定谷歌如何处理这个问题.但在典型的套接字通信中,它在最小程度上是阻塞的.
采访者:您认为如何处理？
我:我猜这个过程会分叉一个新线程并创建一个套接字来处理我的请求.从现在开始,我与Google通信的套接字端点就是这个子套接字.
采访者:如果是这种情况,这个子套接字的端口号是否与父套接字不同？
我:父套接字在80处侦听来自客户端的新请求.孩子必须在不同的端口号上听.
采访者:由于您的目标端口号已更改,您的TCP连接如何维护.(这是在Google的数据包上发送的src-port号码)？
我: 我看到作为客户端的目标端口始终为80.当回复响应时,它也来自端口80.我猜操作系统/父进程将源端口设置回80,然后再发回帖子.
采访者:你的套接字连接与谷歌有多长时间了？
我:如果我在一段时间内没有提出任何请求,主线程会关闭它的子套接字,来自我的任何后续请求都将像我是一个新客户端.
采访者:不,Google不会为您保留专用的子插座.它处理您的请求并立即丢弃/回收插座.
采访者:虽然谷歌可能有很多服务器来处理请求,但每个服务器只能在端口80打开一个父插槽.访问谷歌网页的客户端数量必须大于他们拥有的服务器数量.这通常如何处理？
我:我不确定如何处理.我看到它可以工作的唯一方法是为它收到的每个请求生成一个线程.
采访者:您认为Google处理此问题的方式与任何银行网站不同吗？
我:在TCP-IP套接字级别,它应该是类似的.在请求级别,略有不同,因为维护会话以保持银行网站请求之间的状态.
如果有人可以对每个要点给出解释,那么对于许多网络初学者来说这将是非常有帮助的.
use*_*421 13
Google收到的每个请求都会打开多少个套接字？
这个问题实际上并没有出现在采访中,但它在你的标题中,所以我会回答它.谷歌根本不打开任何套接字.你的浏览器就是那么做 Google 以新套接字的形式接受连接,但我不会将其描述为"打开"它们.
采访者:当我打开浏览器并在其中输入google.com时,请告诉我幕后发生的过程.
我:首先发生的是创建一个由{SRC-IP,SRC-PORT,DEST-IP,DEST-PORT,PROTOCOL}标识的套接字.
不.连接由元组标识.套接字是连接的端点.
SRC-PORT号码是浏览器给出的随机数.
不.由操作系统.
通常是TCP/IP连接协议(建立三次握手).现在,客户端(我的浏览器)和服务器(谷歌)都准备好处理请求.(建立TCP连接)
采访者:等一下,名称解析何时发生？
我:是的,我很抱歉.它应该在创建套接字之前发生.DNS名称解析首先发生以获取谷歌的IP地址到达.
访问者:是否为DNS名称解析创建了一个套接字？
我:嗯,实际上不知道.但我所知道的DNS名称解析是一个无连接.那不是TCP而是UDP.只发生一个请求 - 响应周期.(这是为DNS名称解析创建的新套接字).
任何合理实现的浏览器都会将整个事物委托给操作系统的套接字库,其内部功能取决于操作系统.它可能会在出门到DNS服务器之前查看内存缓存,文件,数据库,LDAP服务器,以及它可以通过TCP或UDP执行的操作.这不是一个很好的问题.
采访者:google.com对其他客户的其他请求开放.所以建立你与谷歌的连接阻止其他用户？
我:我不确定谷歌如何处理这个问题.但在典型的套接字通信中,它在最小程度上是阻塞的.
又错了.它与谷歌没什么关系.TCP服务器每个接受的连接都有一个单独的套接字,任何合理构造的TCP服务器都可以通过多线程,多路复用/非阻塞I/O或异步I/O完全独立地处理它们.它们不会相互阻挡.
采访者:您认为如何处理？
我:我猜这个过程会分叉一个新线程并创建一个套接字来处理我的请求.从现在开始,我与谷歌通信的套接字端点就是这个子套接字.
创建线程,而不是"分叉".分叉进程会创建另一个进程,而不是另一个进程.套接字不是被"创建"的,而是通常在创建线程之前.它不是'儿童'插座.
访问者:如果是这种情况,这个子套接字的端口号是否与父父端口号不同.
我:父套接字在80处侦听来自客户端的新请求.孩子必须在不同的端口号上听.
又错了.接受的套接字使用与侦听套接字相同的端口号,并且接受的套接字根本不是"侦听",它正在接收和发送.
采访者:由于您的Dest-port编号已更改,您的TCP连接如何维护.(这是google数据包上发送的src-port号码)？
我:我看作客户端的目标端口总是80.当请求被发送回来时,它也来自端口80.我猜OS /父进程在发回邮件之前将src端口设置回80 .
此问题旨在探索您之前的错误答案.你继续错误的答案仍然是错误的.
采访者:你的套接字连接与谷歌有多长时间了？
我:如果我在一段时间内没有提出任何请求,主线程会关闭它的子套接字,来自我的任何后续请求就像是一个新客户端.
又错了.你对谷歌的线程一无所知,更不用说哪个线程关闭了套接字.任何一端都可以随时关闭连接.很可能服务器端会击败你,但它并不是一成不变的,如果任何线程都没有这样做的话.
采访者:不,谷歌不会为你保留一个专用的子插座.它处理您的请求并立即丢弃/回收插座.
面试官在这里错了.他似乎没有听说过HTTP keep-alive,或者它是HTTP 1.1中的默认值.
采访者:虽然谷歌可能有很多服务器来处理请求,但每个服务器只能在端口80打开一个父插槽.访问谷歌网页的客户端数量必须超过他们拥有的服务器数量.这通常如何处理？
我:我不确定如何处理.我看到它可以工作的唯一方法是为它收到的每个请求生成一个线程.
在这里你根本没有回答这个问题.他正在寻找关于负载均衡器或循环DNS或所有这些服务器前面的东西的答案.然而,他的句子"访问谷歌网页的客户数量必须超过他们拥有的服务器数量"已经通过你错误地称为"子套接字"的存在来回答.同样,这不是一个很好的问题,除非你报告的不准确.
采访者:您认为Google处理的方式与任何银行网站不同吗？
我:在TCP-IP套接字级别,它应该是类似的.在请求级别,略有不同,因为维护会话以保持Banks网站中的请求之间的状态.
你几乎得到了这个.存在与Google的HTTP会话以及银行网站.这不是什么大问题.他应该询问事实,而不是你的意见.
总体而言,(a)您彻底失败的面试,和(b)你沉迷于远太多猜测.你应该简单地说"我不知道"并让面试继续进行你所知道的事情.