判断是否网络正常原理(如何判断网络是否正常)

终于轮到ajax 了，不容易。

Last, we'll briefly mention AJAX and what it means in the HTTP request/response cycle. AJAX is short for Asynchronous JavaScript and XML. Its main feature is that it allows browsers to issue requests and process responses without a full page refresh. For example, if you're logged into Facebook, the server has to generate the initial page you see, and the response is a pretty complex and expensive HTML page that your browser displays. The Facebook server has to add up all the likes and comments for every photo and status, and present it in a timeline for you. As we described earlier, it's a very expensive page to re-generate for every request (remember, every action you take -- clicking a link, submitting a form -- issues a new request).

Ajax

最后，我们简单的描述AJAX，以及它在HTTP 请求/回复 的循环中的含义。AJAX 是 异步Javascript 和 XML 的简写。它的主要功能是，允许浏览器在不做全页刷新的条件下，发起请求以及处理回复。比如说，如果你登录到facebook，服务端需要生成你看到的初始页面，而且这个回复的HTML界面会比较复杂以及消耗服务器的资源。Facebook 服务器需要对每一页图片和状态添加所有的评论以及喜爱，并以时间线的形式呈现给你。和我们之前描述的一样，这个页面非常复杂，需要重新生成每个请求（记住，你做的每个操作，点击链接，提交表单，生成新的请求）

When AJAX is used, all requests sent from the client are performed asynchronously, which just means that the page doesn't refresh. Let's see an example by performing some search on google:

当使用AJAX 的时候，所有从客户端的请求是异步发起的，这意味着所有的页面不会刷新。让我们看一个用google 搜索的例子：

当你请求https://www.google.com 并打开浏览器的inspector（检察员） 网络表，你会发现网络表是空的：

当你开始你的搜索，你会发现网络表被请求填满。

No doubt you've performed searches many times and notice the page doesn't refresh. The Network tab however gives us some new insight into what's happening: every letter you type is issuing a new request, which means that an AJAX request is triggered with every key-press. The responses from these requests are being processed by some callback. You can think of a callback as a piece of logic you pass on to some function to be executed after a certain event has happened. In this case, the callback is triggered when the response is returned. You can probably guess that the callback that's processing these asynchronous requests and responses is updating the HTML with new search results.

We won't get into what the callback looks like or how to issue an AJAX request, but the main thing to remember is that AJAX requests are just like normal requests: they are sent to the server with all the normal components of an HTTP request, and the server handles them like any other request. The only difference is that instead of the browser refreshing and processing the response, the response is processed by a callback function, which is usually some client-side JavaScript code.

没有疑问的是，你进行了很多次搜索，发现页面并没有刷新。网络表格给了我们很多新的信息，告诉我们发生了什么事情，每次你敲打的时候，会发起一个新的请求，这意味着AJAX 请求会被 “回车键”触发，这些请求的回复被某些回调函数处理。你可以认为回调函数是一个逻辑，当某个事件被触发后，你再传递给某些函数来被执行。在这个条件下，回调函数会被触发，当response被返回。你可能会猜到，处理这些异步请求和回复的回调函数 正在用新的搜索结果来更新HTML 页面。

我们本书不去介绍回调函数长得什么样，或者怎么来发起一个AJAX 请求，不过你需要关注的最重要的事情是，Ajax 请求和正常的请求是一样的，他们和所有普通的请求一样会被送给服务端，而服务端会和所有其它请求一样去处理它。

唯一的区别是，别的请求，浏览器会刷新和处理这个回复，而Ajax的请求， 回复会由一个回调函数处理，一般是客户端的javascript 代码。

This chapter covered techniques used by web developers to mimic statefulness, despite having to work with HTTP, a stateless protocol. You learned about cookies and sessions, and how modern web applications remember state for each client. You also used the inspector to see cookies and the session id in action. Finally, you learned about the role AJAX plays in displaying dynamic content in web applications.

本章节介绍了这些技术，开发者使用了这些技术来模仿一个有状态的服务，虽然下面使用了HTTP，一个无状态的协议。你了解了cookie 和 session，以及现代的web 服务器如何针对每个客户端记忆状态。你也使用了inspector(检察员）来查看正在运行的cookie 以及session id。最后，你学习了Ajax 在web程序中，动态内容中所起的作用。

As we've repeatedly stated throughout this book, the same attributes that make HTTP so difficult to control, also make it so difficult to secure. Now that you know about how web applications dance their way around the statelessness of HTTP, you can probably guess that there are some security ramifications lurking around the corner. For example, what if someone steals my browser's session id, does that mean they can log in as me? Or what if I'm accessing a random website, can they peek into my Reddit or Facebook cookie, where my session id information for those sites are stored? We'll spend this chapter discussing some common security issues that creep up with HTTP. This is by no means an exhaustive list of security issues; just common ones that any web developer would be expected to know.

安全

就像我们在本书中重复的描述，同样的原因让HTTP 如此的难以被控制，也让它变得这么难的实现安全。现在你知道web 应用程序是如何在无状态HTTP底下跳舞的（理解就是上层应用做到有状态），你也大概可以猜测到有一些潜伏在拐角的安全的隐患。比如说，如果一些人偷了我的浏览器的会话ID怎么办？是否这意味着他可以以我的身份进行登录？如果我登录一个随机的web网站，他们是否会偷看我的Reddit 或者 facebook的cookie信息，在cookie里存储了我的信息。我们会用本章节聊一下在HTTP底下潜藏的一些常见的安全问题。这不是一份详细的清单，这仅仅是web 开发者应该需要知道的一些很普通的内容。

As the client and server send requests and responses to each other, all information in both requests and responses are being sent as strings. If a malicious hacker was attached to the same network, they could employ packet sniffing techniques to read the messages being sent back and forth. As we learned previously, requests can contain the session id, which uniquely identifies you to the server, so if someone else copied this session id, they could craft a request to the server and pose as your client, and thereby automatically being logged in without even having access to your username or password.

This is where Secure HTTP, or HTTPS, helps. A resource that's accessed by HTTPS will start with https:// instead of http://, and usually be displayed with a lock icon in most browsers

安全HTTP（HTTPS）

当客户端当客户端和服务端对彼此发送请求和回复，所有的信息都是以字符串的方式来发送的。如果一个恶意的黑客连接到同样的网络中，他们可以使用监听包技术来读来回发送的信息。像我们之前学习到的，请求可以包含会话ID，让你唯一的被服务端所识别，如果某些人拷贝了这个会话ID，他们能够装成你的客户端像服务器发送请求，这样会自动的登录，不需要输入你的用户名或者密码。

在这个场景下，安全HTTP，或者HTTPS可以帮忙。一个通过HTTPS 访问的资源以https:// 开头 而不是http://，会在绝大多数的浏览器中显示一个锁的造型。

With HTTPS every request/response is encrypted before being transported on the network. This means if a malicious hacker sniffed out the HTTP traffic, the information would be encrypted and useless.

HTTPS sends messages through a cryptographic protocol called TLS for encryption. Earlier versions of HTTPS used SSLor Secure Sockets Layer until TLS was developed. These cryptographic protocols use certificates to communicate with remote servers and exchange security keys before data encryption happens. You can inspect these certificates by clicking on the padlock icon that appears before the https://:

每一个HTTPS 的请求/回复 是加密的，然后在传输到网络上。这意味着如果一个恶意的黑客嗅探到了HTTP的流量，信息是加密的而且没办法使用。

HTTPS 使用一个叫TLS的密码协议传递数据，早起的HTTPS版本使用SSL 或者 SSL 层，直到TLS 被开发。这些加密的协议使用证书来和远程的服务端进行通信，互相交换安全key，然后再做数据的加密，你可以通过单击在HTTPS 之前的标志符来查看到这些安全KEY。

Although most modern browsers do some high level check on a website's certificate on your behalf, viewing the certificate sometimes serves as an extra security step before interacting with the website.

虽然绝大多数现代浏览器会代替用户对一些web网站做一些高级别的检查，查看证书有时变成了一个额外的安全步骤，在和website 进行交互之前。

The same-origin policy is an important concept that permits unrestricted interaction between resources originating from the same origin, but restricts certain interactions between resources originating from different origins. What we mean by origin here is the combination of a url's scheme, hostname, and port. So http://mysite.com/doc1 would be considered to have the same origin as http://mysite.com/doc2, but a different origin to https://mysite.com/doc2 (different scheme), http://mysite.com:4000/doc2 (different port), and http://anothersite.com/doc2 (different host).

同源策略：

同源政策是一个很重要的概念，它允许同样的站点的资源无限制的交互，但是限制不同来源的资源之间的一些交互。这里来源的意思是：一个URL的scheme，主机名，端口的混合。所以 http://mysite.com/doc1 被认为和http://mysite.com/doc2 拥有同样的来源，和https://mysite.com/doc2 （协议不同）和 http：//mysite.com:4000/doc2 (端口不同）以及http：//anothersite.com/doc2 ( 站点不同）

Same-origin policy doesn't restrict all cross-origin requests. Requests such as linking, redirects, or form submissions to different origins are typically allowed. Also typically allowed is the embedding of resources from other origins, such as scripts, css stylesheets, images and other media, fonts, and iframes. What is typically restricted are cross-origin requests where resources are being accessed programmatically using APIs such as XMLHttpRequest or fetch (the details of which are beyond the scope of this book).

同源政策不会限制所有的跨源请求，类似连接、重定向、提交表单到不同的区域是被允许的。一般被允许的操作还包括嵌套从其他源获取的资源，比如脚本、CSS 格式化表单，图片以及其它视频、字体等资源。 哪些会被限制？一般是跨源的请求，资源被程序化的使用API进行访问，比如XMLHttpRequest 或者 fetch 操作（详细信息在本书介绍范围之外）

While secure, same-origin policy is an issue for web developers who have a legitimate need for making these restricted kinds of cross-origin requests. Cross-origin resource sharing or CORS was developed to deal with this issue. CORS is a mechanism that allows interactions that would normally be restricted cross-origin to take place. It works by adding new HTTP headers, which allow servers to serve resources cross-origin to certain specified origins.

The same-origin policy is an important guard against session hijacking (see next section) attacks and serves as a cornerstone of web application security. Let's look at some HTTP security threats and their counter-measures.

虽然安全，同源政策对一些有合法需求进行受限类型的跨域请求的web开发人员来说是一个问题。跨源的资源共享，或者CORS 方案被开发出来，来处理这种合理需求场景。CORS 是一个机制，允许一些一般会被禁止的跨源的操作能否发生。它通过增加一个HTTP 头，这个头可以允许服务端针对某些特殊的来源提供跨域的资源。

同源政策对于会话劫持攻击是非常重要的一个保护（看下一段），是web 应用安全的基石, 让我们再来看一些HTTP的安全威胁，以及对应的防范策略。