客户端/服务器程序
Introduction
介绍
HyperText Transfer Protocol or "HTTP" is the underpinning of internet communication. As a teacher of web development I have heard many questions, mostly from my younger students who have come to the WWW in the days after 2005 (and therefore after the advent of jQuery), that seem to evince a misunderstanding of the way the HTTP protocol works. Since HTTP is the basic building block of web sites and web applications, a clear understanding of the protocol is required to understand how web sites really work. And perhaps more importantly, it is necessary to understand the protocol so you can build a web site that works like another site you've seen and appreciated. This article is intended to lift the cloud of confusion that has appeared in the years since the arrival of 超文本传输协议或“ HTTP”是Internet通信的基础。 作为Web开发的老师，我听到了很多问题，主要是我的年轻学生在2005年之后（因此jQuery出现之后）来到了WWW，这似乎是对HTTP协议方式的误解。作品。 由于HTTP是网站和Web应用程序的基本构建块，因此需要对协议有一个清晰的了解，以了解网站的实际工作方式。 也许更重要的是，有必要了解该协议，以便您可以构建一个网站，该网站的工作方式类似于您已经看到并欣赏过的另一个网站。 本文旨在消除自 jQuery, jQuery ， CSS3, animation in web sites, and the phenomenon called CSS3 ，网站中的动画以及称为 Web 2.0. Web 2.0的现象出现以来的几年中出现的混乱云。The confusion has arisen in large measure because of the design movement of web interactivity away from the static page loads and into design paradigms that more closely mimic native applications. If the hyperlink was the design element that launched the internet revolution, the event handler may be thought of as the design element that has most refined the client experience. In all cases, at the foundation is the HTTP protocol.
由于Web交互的设计运动从静态页面加载转移到更紧密地模仿本机应用程序的设计范例中，因此在很大程度上产生了混乱。 如果超链接是引发互联网革命的设计元素，那么可以将视为最能改善客户体验的设计元素。 在所有情况下，HTTP协议都是基础。
HTTP is a Stateless Client/Server Protocol
HTTP是无状态的客户端/服务器协议
Client/Server protocols are two-way communication mechanisms that allow humans to get information from web sites. These same protocols also allow computers to talk to one another, share data, and react in real time to changes in their environment. The starting point for any communication, and a basic building block of the protocol is a request. If you want to delve deeply into this concept, see Roy Fielding's dissertation that coined the phrase REST. The entire WWW is built on RESTful communications.
客户端/服务器协议是双向通讯机制，可让人们从网站获取信息。 这些相同的协议还允许计算机彼此交谈 ，共享数据并实时响应其环境的变化。 任何通信的起点和协议的基本组成部分都是罗伊·菲尔丁（Roy Fielding）的论文 ，该论文造就了REST。 整个WWW基于RESTful通信。
By definition, the client machine makes the request. And the server machine makes the response. Without the request, nothing happens on the internet. The only thing that the server can do is make a response after it has received a request. Otherwise the server sits idle, in stateless ignorance of the rest of the world-wide web.
根据定义， 在收到后做出
When you grasp this concept, you've got a good understanding of one of the most essential building blocks of modern computing.
掌握了这一概念后，您就对现代计算的最基本组成部分之一有了很好的了解。
Clients make Requests
客户提出要求
THENServers make Responses
服务器做出响应
The only way that any internet communication can be initiated is with a request. Servers cannot initiate communications with a client. This is true, in part, because of security considerations. Consider what would happen if a server could start some kind of application running on your home computer without your knowledge or permission. Your family room could suddenly become a source of email spam or financial fraud. The attacking server could turn your computer into a "zombie" that spread viruses to other computers. Obviously this is unacceptable. So servers by their very nature are limited to "servicing" the requests that have been received from their clients. It follows that there is a predictable timeline: the client request happens first and the server response happens next.
可以启动任何Internet通信的唯一方法是发出请求。 服务器无法启动与客户端的通信。 之所以如此，部分是因为出于安全考虑。 考虑一下，如果服务器在您不知情或未经许可的情况下启动家用计算机上运行的某种应用程序会发生什么情况。 您的家庭活动室可能突然成为电子邮件垃圾邮件或财务欺诈的来源。 攻击服务器可能会将您的计算机变成“僵尸”，将病毒传播到其他计算机。 显然，这是不可接受的。 因此，服务器本质上仅限于“服务”从其客户端收到的请求。 因此，有一个可预测的时间表：客户端请求首先发生，服务器响应随后发生。
The Nature of the Stateless Protocol
无状态协议的性质
The client request to the server is often described as "atomic, complete and stateless." The server response is described as "complete" and usually instantaneous. Let's deconstruct these terms to show what the words really mean.
客户端对服务器的请求通常被描述为“原子的，完整的和无状态的” 。 服务器响应被描述为“完成”，通常是瞬时的。 让我们解构这些术语以显示单词的真正含义。
The "atomic" nature of a client request means that the request exists as a standalone data element in the world of the internet. Many clients may make exactly the same request to a server. But for the request to be the "same" each such request must send exactly the same information. In chemistry an atom is made up from protons, neutrons and electrons, and cannot be subdivided; it is a single element. In the HTTP protocol, the request is made up from a URL, headers (including HTTP cookies) and client-supplied data. And like an element, a request cannot be subdivided.
客户请求的“原子”性质意味着该请求作为独立的数据元素存在于Internet世界中。 许多客户端可能会对服务器发出完全相同的请求。 但是，要使请求成为“相同”请求，每个此类请求必须发送完全相同的信息。 在化学中，原子由质子，中子和电子组成，不能细分。 它是一个元素。 在HTTP协议中，请求由URL，标头（包括HTTP cookie）和客户端提供的数据组成。 就像元素一样，无法细分请求。
The "complete" nature of a client request means that the request contains all of the external information that the server can use to respond to the request. The server cannot go back to the client to get any more information. The request is a one-way communication. Once sent, the client has nothing more to say to the server. (Note that the server may use other non-request information to respond to the client, but this is not the same as getting additional information from the client.)
客户请求的“完成”性质意味着该请求包含服务器可以用来响应该请求的所有外部信息。 服务器无法返回到客户端以获取更多信息。 该请求是单向通信。 发送后，客户端对服务器无话可说。 （请注意，服务器可能会使用其他
The "stateless" nature of a client request is subtle and a bit more complicated. It means, in general terms, that the client and server know nothing of each other except what is presented in the request and returned in the response. In the current environment of web interactivity, this truth may be obscured. We all know that we can "log in" to a web site, and that the web site "remembers" our status. Despite the appearance of memory, the fact of statelessness remains. The appearance of stateful behavior is a stratagem, accomplished through the use of HTTP cookies and server-side data bases.
客户请求的“ 无状态 ”本质是微妙的，并且更加复杂。 一般而言，这意味着客户端和服务器彼此之间什么都不知道，除了请求中显示的内容和响应中返回的内容之外。 在当前的Web交互环境中，这个事实可能会被掩盖。 我们都知道我们可以“登录”网站，并且该网站“记住”我们的状态。 尽管出现了内存，但无状态仍然存在。 有状态行为的出现是一种策略，通过使用HTTP cookie和服务器端数据库来完成。
HTTP Headers Must Come First, Period
HTTP标头必须居首
It is a law of HTTP that headers must come first and be complete before any browser output can be sent. This rule includes even invisible white space characters. The server is responsible for implementing this rule, and failure to comply has consequences that include the risk of lost data.
根据HTTP的法律，在发送任何浏览器输出之前， 标头必须首先出现并且完整。 此规则甚至包括不可见的空格字符。 服务器负责实施此规则，不遵守将导致后果，包括丢失数据的风险。
In writing PHP scripts the programmer must be aware of this "headers-first" rule and deliberately avoid sending browser output at an inappropriate time. Since HTTP cookies are part of the HTTP headers, it follows that no browser output can precede the use of setcookie(). What may not be completely obvious is that the PHP session_start() function implicitly calls setcookie(). When coupled with the fact that invisible white space can trigger browser output, this may become a point of confusion. Consider the code snippet to see why. This script will fail to start the session because the invisible white space that is the end-of-line character is in the browser output stream after line 1.
在编写PHP脚本时，程序员必须意识到这一“从头开始”的规则，并有意避免在不适当的时间发送浏览器输出。 由于HTTP cookie是HTTP标头的一部分，因此，在使用setcookie（）之前，没有浏览器输出。 可能并不完全明显的是，PHP session_start（）函数隐式调用setcookie（）。 再加上不可见的空格可能触发浏览器输出的事实，这可能会引起混乱。 考虑一下代码片段以了解原因。 该脚本将无法启动会话，因为作为行尾字符的不可见空格位于第1行之后的浏览器输出流中。
<?php error_reporting(E_ALL); ?>
<?php session_start();
// ETC
If your PHP script generates a Warning message that says something to the effect of "cannot modify headers" the script has run afoul of the "headers-first" rule. One of the solutions here, either refactor or buffer, will solve the problem.
如果您PHP脚本生成警告消息，说明“无法修改标头”，则表明该脚本违反了“标头优先”规则。 此处的一种解决方案，无论是重构还是缓冲，都可以解决该问题。
Learn more here about HTTP headers.
Using HTTP Cookies and Server-Side Data Bases to Appear Stateful
使用HTTP Cookies和服务器端数据库显示状态
In the normal course of creating a response, a server can send an HTTP cookie to the browser and the browser can return the cookie to the server on each subsequent request. This concept (and with it, the end of privacy on the internet) came about in 1994. The typical HTTP cookie is a very small data file. Usually it contains information that provides a key to a server-side repository of client information. Upon receiving a request that contains a cookie the server can look up the information in its repository, tailor its response to the client, and thus appear to have an understanding of the state of the client. Used correctly, cookies allow us to become "logged in" to a web site, to have a "shopping cart" or "wish list" or to have a server "remember" our preferences. Cookies enable the server to recognize its clients on second and subsequent visits.
在创建响应的正常过程中，服务器可以将HTTP cookie发送到浏览器，浏览器可以在每次后续请求时将cookie返回给服务器。 这个概念（随之而来的是互联网隐私的终结）于1994年问世。典型的HTTP cookie是一个非常小的数据文件。 通常，它包含提供客户端信息服务器端存储库密钥的信息。 在接收到包含cookie的请求时，服务器可以在其存储库中查找信息，调整其对客户端的响应，因此似乎了解客户端的状态。 正确使用Cookie可以使我们“登录”网站，拥有“购物车”或“愿望清单”或让服务器“记住”我们的偏好。 Cookies使服务器能够在第二次及以后的访问中识别其客户端。
Any client machine that sends an identical cookie will cause the server to locate the same repository of client information. (It is the server's responsibility to ensure that the cookies it receives are authentic; without such verification security breaches and forgeries are possible.) And a client machine that does not send the cookie(s) will not be treated in the stateful way -- without the cookie, the server cannot locate the repository of client information and the server will simply not recognize the request as one in a series from a known client.
任何发送相同Cookie的客户端计算机都将导致服务器找到客户端信息的相同存储库。 （服务器的责任是确保接收到的cookie是真实的；没有这种验证，可能会违反安全性和伪造 。）而且，不发送cookie的客户端计算机将不会以有状态方式处理-如果没有Cookie，则服务器无法定位客户端信息的存储库，并且服务器将无法简单地将请求识别为来自已知客户端的一系列请求。
Knowledgeable computer scientists may recognize edge cases where these statements are not strictly true, but for the overwhelming majority of internet activity today (March 2013) the principles hold their ground, and artful server-side programming is required to bend the principles even a little bit.
博学多才的计算机科学家可能会认识到这些情况并非严格正确，但对于当今绝大多数互联网活动（2013年3月）而言，这些原则仍然立于不败之地，并且需要精巧的服务器端编程才能将这些原则稍加修改。
With or without cookies, each HTTP request is a standalone, stateless event. With cookies, the client and server can work together to create the appearance of server-side knowledge of the state of the client.
有无cookie，每个HTTP请求都是一个独立的无状态事件。 借助cookie，客户端和服务器可以一起工作，以创建客户端状态的服务器端知识的外观。
Developer Madness and Shared Cookie Jars
开发人员疯狂和共享Cookie罐
There is a phenomenon of modern browsers that is never a problem for clients, but that drives application developers insane, until they learn the nature of how browsers store cookies. All instances of the same browser share the same "cookie jar" file. This means that if you have a browser running in different tabs or even in different windows every page load will send the same set of cookies with the HTTP request.
现代浏览器存在一种现象，它永远不会对客户端造成问题，但会导致应用程序开发人员疯狂，直到他们了解浏览器如何存储Cookie的本质。 同一浏览器的所有
Consider this scenario. The developer opens a browser window and visits his test site under the identity of User1. He logs in and adds some products to his shopping cart. Then, to test alternate functionality, the developer opens another browser window and logs in as User2. Satisfied that things look right, he closes window number two and goes back to window number one, and to his horror, everything is wrong. He's not user User1 any more. The site seems to think he is User2 now, but he has User1 items in his shopping cart. The site appears to be very badly broken and the developer begins tearing his hair out. Actually, it's working correctly. Here is the timeline of what just happened,
考虑这种情况。 开发人员打开浏览器窗口，并以
1. Client GET request to test web site receives a Session cookie from the server
1.测试网站的客户端GET请求从服务器接收到会话cookie
2. Client POST request to log in as User1 sends the Session cookie back to the site
2.客户端POST请求以
3. Server authenticates the log in and creates the server-side session data for User1
3.服务器对登录进行身份验证并为
4. Client POST request to add product to cart receives a Cart cookie from the server
4.将产品添加到购物车的客户端POST请求从服务器接收到购物车cookie
5. At this point, Client has two cookies and opens window number two
5.此时，客户端有两个cookie，并打开第二个窗口
6. Client GET request sends both Session and Cart cookies
6.客户端GET请求发送会话和购物车Cookie
7. Client POST request to log in as User2 sends both Session and Cart cookies
7.当
8. Server authenticates the log in, and changes the server-side session data to User2
8.服务器对登录进行身份验证，然后将服务器端会话数据更改为
9. The Session cookie now points to server data for User2, but the Cart cookie is intact
9.现在，会话cookie指向
10. Client closes window number two.
10.客户关闭第二个窗口。
11. Using window number one, client makes a request to the server sending the existing cookies. The Session cookie points to the server-side data for User2. The Cart cookie points to server-side data for User1. The developer is stupefied.
11.使用第一个窗口，客户端向发送现有cookie的服务器发出请求。 会话cookie指向
The single cookie jar never causes confusion in the "real world" because clients do not bounce back and forth between different identities. They visit web sites but don't do the kinds of fiddly things that developers do when testing. And developers, if they are knowledgeable of browser and cookie behavior, will know to use different machines (or at least different browsers) when testing different client behaviors!
单个cookie罐决不会在“现实世界”中引起混乱，因为客户端不会在不同的身份之间来回跳动。 他们访问网站，但不执行开发人员在测试时所做的那种简单的事情。 如果开发人员了解浏览器和cookie行为，他们将知道在测试不同的客户端行为时使用不同的机器（或至少使用不同的浏览器）！
Should the server have deleted the Cart cookie at the time of User2 log in? Maybe. But a better strategy might be a single and idempotent cookie to identify the user. The server can keep track of lots of information associated with a single cookie. And the risk of confusion is minimized.
服务器在幂等 cookie来标识用户。 服务器可以跟踪与单个cookie相关的大量信息。 并且将混乱的风险降到最低。
The Timeline of Request and Response
请求和响应的时间表
The client request precedes the server response and is completed before the server can begin to formulate its response. The server response is completed before the client's browser output begins. And while there are edge cases that may appear to bend this timeline slightly, the true nature of the HTTP protocol remains unchanged.
客户端请求先于服务器响应，并在服务器可以开始制定其响应之前完成。 在客户端的浏览器输出开始之前，服务器响应已完成。 尽管在某些情况下可能会稍微改变此时间轴，但HTTP协议的真实性质保持不变。
When a client requests a web page, the server creates the web page using program logic and data that is stored on the server (example: PHP and MySQL data bases). This information is packaged into the client-side information that takes the form of HTML, CSS, JavaScript and other content. Once packaged, the server sends the response and disconnects from the network. It follows that the server, having sent the response and disconnected, can no longer modify any part of the response. This is why server-side PHP scripts cannot react to client actions until another request is received. This is also why it is impossible for the server to know how long a client has been "on the page."
当客户端请求网页时，服务器使用程序逻辑和存储在服务器上的数据（例如：PHP和MySQL数据库）创建网页。 此信息打包为HTML，CSS，JavaScript和其他内容形式的客户端信息。 打包后，服务器将发送响应并断开与网络的连接。 因此，已发送响应并断开连接的服务器无法再修改响应的任何部分。 这就是为什么服务器端PHP脚本在收到另一个请求之前不能对客户端操作做出React的原因。 这也是为什么服务器无法知道客户端在页面上停留了多长时间的原因。
Using JQuery/AJAX Requests to Build Good Client User-Experience
使用JQuery / AJAX请求建立良好的客户端用户体验
Even though your server cannot talk to the client more than once per request, you can build the appearance of client-server interactivity through AJAX requests. AJAX enables the client machine to send the HTTP request and receive the server response without reloading the entire web page. Typically only a portion of the data in the browser viewport will be replaced. This technology relies on JavaScript to affect the request and receive the response. A Javascript framework, usually jQuery, is employed to ease the client-side programming. There is an article here at EE demonstrating the "hello world" exercise with jQuery and AJAX.
即使您的服务器不能与每个请求多次与客户端对话，您仍可以通过AJAX请求构建客户端与服务器交互的外观。 AJAX使客户端计算机能够发送HTTP请求并接收服务器响应， Javascript框架 （通常为jQuery ）来简化客户端编程。 EE上有一篇文章演示了jQuery和AJAX的“ hello world”练习。
JavaScript can react to a variety of environmental changes on the client machine. These changes are associated with "event handlers" that get triggered by actions such as page loads, mouse movement, keystrokes, etc. One example of an event handler is the onKeyUp handler that captures the moment at which a previously pressed key is released. Using this event handler, JavaScript can grab the contents of a form input control and initiate an AJAX request to the server. The server can take the information from the request, perform a data base lookup and respond to the client machine. This design allows an auto-complete or suggestion to appear in the client viewport.
JavaScript可以对客户端计算机上的各种环境变化做出React。 这些更改与“ 事件处理程序 ”相关联，“ 事件处理程序 ”由诸如页面加载，鼠标移动，击键等操作触发。事件处理程序的一个示例是onKeyUp处理程序，它捕获释放先前按下的键的时刻。 使用此事件处理程序，JavaScript可以获取表单输入控件的内容，并向服务器发起AJAX请求。 服务器可以从请求中获取信息，执行数据库查找并响应客户端计算机。 这种设计允许自动完成或建议出现在客户端视口中。
JavaScript can set timers, and event handlers can respond to the expiration of timers by making AJAX requests to the server and replacing parts of the viewport. Your JavaScript could, for example, initiate a request to the server every second. When something interesting is found on the server, a response can be made to indicate the interesting thing to the client. This activity can produce the illusion that the "server is calling the client" with things like the announcement of new email messages, or a popup notice about a special discount.
JavaScript可以设置计时器，事件处理程序可以通过向服务器发出AJAX请求并替换部分视口来响应计时器的到期。 例如，您JavaScript可以每秒向服务器发起一个请求。 当在服务器上找到有趣的东西时，可以做出响应以将有趣的东西指示给客户端。 此活动可能会产生一种幻象，即“服务器正在呼叫客户端”，并带有诸如宣布新电子邮件消息或有关特殊折扣的弹出通知之类的信息。
Conclusion
结论
Even though "Web 2.0" applications may appear to contain server-initiated communication, that is not the case. Client/server protocols and principles still apply, even if the human client cannot see them in action. And while a complete page load need not be part of the server's response, the response is only made after receiving a request from the client machine.
即使“ Web 2.0”应用程序似乎包含服务器启动的通信，事实并非如此。 客户端/服务器协议和原则仍然适用，即使人类客户端无法看到它们在行动。 而且，虽然完整的页面加载不一定是服务器响应的一部分，但是仅在从客户端计算机收到请求后才做出响应。
Please give us your feedback!
请给我们您的反馈意见！
If you found this article helpful, please click the "thumb's up" button below. Doing so lets the E-E community know what is valuable for E-E members and helps provide direction for future articles. If you have questions or comments, please add them. Thanks!
如果您发现本文有帮助，请单击下面的“竖起大拇指”按钮。 这样做可以使EE社区了解对EE成员有价值的内容，并为将来的文章提供指导。 如果您有任何问题或意见，请添加。 谢谢！
客户端/服务器程序
121
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
