虽然您的网络服务器知道较低层协议中的一些信息，但它并没有真正利用它做太多事情。这主要是由操作系统库处理的，操作系统库最终将一些原始 HTTP 数据交给 Web 服务器，然后 Web 服务器开始处理这些数据。
再添加一层，HTTP 与幕后运行的网关语言无关。这是相当明显的，因为无论 Web 服务器是提供 CGI Perl 脚本、PHP、ASP.Net 还是静态 HTML 文件，协议都是相同的。 HTTP 只是发出请求，然后网络服务器相应地处理该请求。
希望这能为您澄清一些概念，并让您更好地了解您想要理解的内容。
It seems like you're having a little trouble separating out the different parts of your question so I'll do my best to help you out with that.
First and foremost, a common method for understanding communication between two computers is described using what is called the OSI model. This model attempts to distinguish the responsibilities between each protocol in a protocol stack. For example, when you surf a website on your home network the protocol stack is most likely something like
Ethernet-IPv4-TCP-HTTP
This modularization of protocols is used to create a separation of concerns so that developers don't have to "reinvent the wheel" each time they try to get two computers to communicate in some way. If you're trying to write a chat program you don't want to worry about packet loss or internet routing methodologies so you go ahead and take advantage of the lower level protocols that already exist and handle more of the nitty gritty stuff for you.
When people refer to socket communication these days they're typically using TCP or UDP. These are both known as transport protocols. If you'd like to learn more of the fine details on socket communication I would start with UDP because it's a simpler protocol and then move on to TCP.
While your web server is aware of some information in the lower level protocols it doesn't really do much with it. Primarily that's all handled by the operating system libraries which eventually hand the web server some raw HTTP data which the web server then begins to process.
To add another layer, HTTP has nothing to do with the gateway language running behind the scenes. This is fairly obvious due to the fact that the protocol is the same whether the web server is serving CGI perl scripts, PHP, ASP.Net or static HTML files. HTTP simply makes the request and the webserver processes the request accordingly.
Hopefully this clarifies a few concepts for you and gives you a better idea what you're trying to understand.
It depends on the server. An apache 2 server could do any amount of request rewriting, automatic responses (301, 303, 307, 403, 404, 500) based on rules, starting a CGI script, exchanging data with a FastCGI script, passing some data to a script module like mod_php, and so on. The CouchDB web server would do something else entirely.
Basically, aside from parsing the request and sending back the appropriate response, there's no real common aspect to web servers.
You could try looking into the documentation of the various web servers: Apache, IIS, lighttpd, nginx...
发布评论
评论（3）
您似乎在区分问题的不同部分时遇到了一些困难，所以我会尽力帮助您解决这个问题。
首先也是最重要的，使用所谓的 OSI 模型。该模型试图区分协议栈中每个协议之间的职责。例如，当您在家庭网络上浏览网站时，协议栈很可能类似于
这种模块化的协议用于创建关注点分离，以便开发人员每次尝试时都不必“重新发明轮子”让两台计算机以某种方式进行通信。如果您正在尝试编写聊天程序，您不想担心数据包丢失或互联网路由方法，因此您可以继续利用现有的较低级别协议并为您处理更多具体内容。
如今，当人们提到套接字通信时，他们通常使用 TCP 或 UDP。这些都称为传输协议。如果您想了解有关套接字通信的更多详细信息，我将从 UDP 开始，因为它是一个更简单的协议，然后继续学习 TCP。
虽然您的网络服务器知道较低层协议中的一些信息，但它并没有真正利用它做太多事情。这主要是由操作系统库处理的，操作系统库最终将一些原始 HTTP 数据交给 Web 服务器，然后 Web 服务器开始处理这些数据。
再添加一层，HTTP 与幕后运行的网关语言无关。这是相当明显的，因为无论 Web 服务器是提供 CGI Perl 脚本、PHP、ASP.Net 还是静态 HTML 文件，协议都是相同的。 HTTP 只是发出请求，然后网络服务器相应地处理该请求。
希望这能为您澄清一些概念，并让您更好地了解您想要理解的内容。
It seems like you're having a little trouble separating out the different parts of your question so I'll do my best to help you out with that.
First and foremost, a common method for understanding communication between two computers is described using what is called the OSI model. This model attempts to distinguish the responsibilities between each protocol in a protocol stack. For example, when you surf a website on your home network the protocol stack is most likely something like
This modularization of protocols is used to create a separation of concerns so that developers don't have to "reinvent the wheel" each time they try to get two computers to communicate in some way. If you're trying to write a chat program you don't want to worry about packet loss or internet routing methodologies so you go ahead and take advantage of the lower level protocols that already exist and handle more of the nitty gritty stuff for you.
When people refer to socket communication these days they're typically using TCP or UDP. These are both known as transport protocols. If you'd like to learn more of the fine details on socket communication I would start with UDP because it's a simpler protocol and then move on to TCP.
While your web server is aware of some information in the lower level protocols it doesn't really do much with it. Primarily that's all handled by the operating system libraries which eventually hand the web server some raw HTTP data which the web server then begins to process.
To add another layer, HTTP has nothing to do with the gateway language running behind the scenes. This is fairly obvious due to the fact that the protocol is the same whether the web server is serving CGI perl scripts, PHP, ASP.Net or static HTML files. HTTP simply makes the request and the webserver processes the request accordingly.
Hopefully this clarifies a few concepts for you and gives you a better idea what you're trying to understand.
这取决于服务器。 apache 2 服务器可以进行任意数量的请求重写、基于规则的自动响应（301、303、307、403、404、500）、启动 CGI 脚本、与 FastCGI 脚本交换数据、将一些数据传递到脚本模块例如
mod_php等等。 CouchDB Web 服务器会做完全不同的事情。基本上，除了解析请求并发回适当的响应之外，Web 服务器没有真正的共同点。
您可以尝试查看各种 Web 服务器的文档：Apache、IIS、lighttpd、nginx...
It depends on the server. An apache 2 server could do any amount of request rewriting, automatic responses (301, 303, 307, 403, 404, 500) based on rules, starting a CGI script, exchanging data with a FastCGI script, passing some data to a script module like
mod_php, and so on. The CouchDB web server would do something else entirely.Basically, aside from parsing the request and sending back the appropriate response, there's no real common aspect to web servers.
You could try looking into the documentation of the various web servers: Apache, IIS, lighttpd, nginx...