diff options
Diffstat (limited to 'files/my/web/http')
| -rw-r--r-- | files/my/web/http/connection_management_in_http_1.x/index.html | 86 | ||||
| -rw-r--r-- | files/my/web/http/index.html | 90 |
2 files changed, 176 insertions, 0 deletions
diff --git a/files/my/web/http/connection_management_in_http_1.x/index.html b/files/my/web/http/connection_management_in_http_1.x/index.html new file mode 100644 index 0000000000..201f93a64c --- /dev/null +++ b/files/my/web/http/connection_management_in_http_1.x/index.html @@ -0,0 +1,86 @@ +--- +title: Connection management in HTTP/1.x +slug: Web/HTTP/Connection_management_in_HTTP_1.x +translation_of: Web/HTTP/Connection_management_in_HTTP_1.x +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary">การจัดการการเชื่อมต่อเป็นหัวข้อสำคัญใน HTTP: การเปิดและรักษาการเชื่อมต่อส่วนใหญ่มีผลต่อประสิทธิภาพของเว็บไซต์และแอปพลิเคชันเว็บ ใน HTTP / 1.x มีหลายโมเดล: <em>การเชื่อมต่อสั้น ๆ</em> , <em>การเชื่อมต่อแบบถาวร</em>และ<em>HTTP pipelining</em></p> + +<p>HTTP ส่วนใหญ่อาศัย TCP สำหรับโปรโตคอลการขนส่งโดยให้การเชื่อมต่อระหว่างไคลเอนต์และเซิร์ฟเวอร์ ในวัยเด็ก HTTP ใช้แบบจำลองเดียวเพื่อจัดการการเชื่อมต่อดังกล่าว การเชื่อมต่อเหล่านี้มีอายุการใช้งานสั้น: การเชื่อมต่อใหม่ที่สร้างขึ้นทุกครั้งที่จำเป็นต้องส่งคำขอและจะปิดเมื่อได้รับคำตอบ</p> + +<p>โมเดลที่เรียบง่ายนี้มีข้อ จำกัด ด้านประสิทธิภาพโดยธรรมชาติ: การเปิดการเชื่อมต่อ TCP แต่ละครั้งเป็นการดำเนินการที่ใช้ทรัพยากรมาก ต้องแลกเปลี่ยนข้อความหลายข้อความระหว่างไคลเอนต์และเซิร์ฟเวอร์ เวลาในการตอบสนองของเครือข่ายและแบนด์วิดท์มีผลต่อประสิทธิภาพเมื่อคำขอต้องการส่ง หน้าเว็บสมัยใหม่ต้องการคำขอจำนวนมาก (ตั้งแต่หนึ่งโหลขึ้นไป) เพื่อให้บริการข้อมูลตามจำนวนที่ต้องการซึ่งพิสูจน์ได้ว่ารุ่นก่อนหน้านี้ไม่มีประสิทธิภาพ</p> + +<p>รุ่นใหม่กว่าสองรุ่นถูกสร้างขึ้นใน HTTP / 1.1 โมเดลการเชื่อมต่อแบบต่อเนื่องช่วยให้การเชื่อมต่อเปิดระหว่างคำขอที่ต่อเนื่องลดเวลาที่ต้องใช้ในการเปิดการเชื่อมต่อใหม่ รูปแบบการไปป์ไลน์ HTTP ก้าวไปอีกขั้นด้วยการส่งคำขอต่อเนื่องหลายรายการโดยไม่ต้องรอคำตอบช่วยลดเวลาแฝงในเครือข่ายได้มาก</p> + +<p><img alt="Compares the performance of the three HTTP/1.x connection models: short-lived connections, persistent connections, and HTTP pipelining." src="https://mdn.mozillademos.org/files/13727/HTTP1_x_Connections.png" style="height: 538px; width: 813px;"></p> + +<div class="note"> +<p>HTTP / 2 เพิ่มโมเดลเพิ่มเติมสำหรับการจัดการการเชื่อมต่อ</p> +</div> + +<p>It's important point to note that connection management in HTTP applies to the connection between two consecutive nodes, which is <a href="/en-US/docs/Web/HTTP/Headers#hbh">hop-by-hop</a> and not <a href="/en-US/docs/Web/HTTP/Headers#e2e">end-to-end</a>. The model used in connections between a client and its first proxy may differ from the model between a proxy and the destination server (or any intermediate proxies). The HTTP headers involved in defining the connection model, like {{HTTPHeader("Connection")}} and {{HTTPHeader("Keep-Alive")}}, are <a href="/en-US/docs/Web/HTTP/Headers#hbh">hop-by-hop</a> headers with their values able to be changed by intermediary nodes.</p> + +<p>A related topic is the concept of HTTP connection upgrades, wherein an HTTP/1.1 connection is upgraded to a different protocol, such as TLS/1.0, WebSocket, or even HTTP/2 in cleartext. This <a href="/en-US/docs/Web/HTTP/Protocol_upgrade_mechanism">protocol upgrade mechanism</a> is documented in more detail elsewhere.</p> + +<h2 id="Short-lived_connections">Short-lived connections</h2> + +<p>The original model of HTTP, and the default one in HTTP/1.0, is <em>short-lived connections</em>. Each HTTP request is completed on its own connection; this means a TCP handshake happens before each HTTP request, and these are serialized.</p> + +<p>The TCP handshake itself is time-consuming, but a TCP connection adapts to its load, becoming more efficient with more sustained (or warm) connections. Short-lived connections do not make use of this efficiency feature of TCP, and performance degrades from optimum by persisting to transmit over a new, cold connection.</p> + +<p>This model is the default model used in HTTP/1.0 (if there is no {{HTTPHeader("Connection")}} header, or if its value is set to <code>close</code>). In HTTP/1.1, this model is only used when the {{HTTPHeader("Connection")}} header is sent with a value of <code>close</code>.</p> + +<div class="note"> +<p>Unless dealing with a very old system, which doesn't support a persistent connection, there is no compelling reason to use this model.</p> +</div> + +<h2 id="Persistent_connections">Persistent connections</h2> + +<p>Short-lived connections have two major hitches: the time taken to establish a new connection is significant, and performance of the underlying TCP connection gets better only when this connection has been in use for some time (warm connection). To ease these problems, the concept of a <em>persistent connection</em> has been designed, even prior to HTTP/1.1. Alternatively this may be called a <em>keep-alive connection</em>.</p> + +<p>A persistent connection is one which remains open for a period of time, and can be reused for several requests, saving the need for a new TCP handshake, and utilizing TCP's performance enhancing capabilities. This connection will not stay open forever: idle connections are closed after some time (a server may use the {{HTTPHeader("Keep-Alive")}} header to specify a minimum time the connection should be kept open).</p> + +<p>Persistent connections also have drawbacks; even when idling they consume server resources, and under heavy load, {{glossary("DoS attack", "DoS attacks")}} can be conducted. In such cases, using non-persistent connections, which are closed as soon as they are idle, can provide better performance.</p> + +<p>HTTP/1.0 connections are not persistent by default. Setting {{HTTPHeader("Connection")}} to anything other than <code>close</code>, usually <code>retry-after</code>, will make them persistent.</p> + +<p>In HTTP/1.1, persistence is the default, and the header is no longer needed (but it is often added as a defensive measure against cases requiring a fallback to HTTP/1.0).</p> + +<h2 id="HTTP_pipelining">HTTP pipelining</h2> + +<div class="note"> +<p>HTTP pipelining is not activated by default in modern browsers:</p> + +<ul> + <li>Buggy <a href="https://en.wikipedia.org/wiki/Proxy_server">proxies</a> are still common and these lead to strange and erratic behaviors that Web developers cannot foresee and diagnose easily.</li> + <li>Pipelining is complex to implement correctly: the size of the resource being transferred, the effective <a href="https://en.wikipedia.org/wiki/Round-trip_delay_time">RTT</a> that will be used, as well as the effective bandwidth, have a direct incidence on the improvement provided by the pipeline. Without knowing these, important messages may be delayed behind unimportant ones. The notion of important even evolves during page layout! HTTP pipelining therefore brings a marginal improvement in most cases only.</li> + <li>Pipelining is subject to the <a href="https://en.wikipedia.org/wiki/Head-of-line_blocking">HOL</a> problem.</li> +</ul> + +<p>For these reasons, pipelining has been superseded by a better algorithm, <em>multiplexing</em>, that is used by HTTP/2.</p> +</div> + +<p>By default, <a href="/en-US/docs/Web/HTTP" title="en/HTTP">HTTP</a> requests are issued sequentially. The next request is only issued once the response to the current request has been received. As they are affected by network latencies and bandwidth limitations, this can result in significant delay before the next request is <em>seen</em> by the server.</p> + +<p>Pipelining is the process to send successive requests, over the same persistent connection, without waiting for the answer. This avoids latency of the connection. Theoretically, performance could also be improved if two HTTP requests were to be packed into the same TCP message. The typical <a href="https://en.wikipedia.org/wiki/Maximum_segment_size">MSS</a> (Maximum Segment Size), is big enough to contain several simple requests, although the demand in size of HTTP requests continues to grow.</p> + +<p>Not all types of HTTP requests can be pipelined: only {{glossary("idempotent")}} methods, that is {{HTTPMethod("GET")}}, {{HTTPMethod("HEAD")}}, {{HTTPMethod("PUT")}} and {{HTTPMethod("DELETE")}}, can be replayed safely: should a failure happen, the pipeline content can simply be repeated.</p> + +<p>Today, every HTTP/1.1-compliant proxy and server should support pipelining, though many have limitations in practice: a significant reason no modern browser activates this feature by default.</p> + +<h2 id="Domain_sharding">Domain sharding</h2> + +<div class="note"> +<p>Unless you have a very specific immediate need, don't use this deprecated technique; switch to HTTP/2 instead. In HTTP/2, domain sharding is no longer useful: the HTTP/2 connection is able to handle parallel unprioritized requests very well. Domain sharding is even detrimental to performance. Most HTTP/2 implementations use a technique called <a href="https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/">connection coalescing</a> to revert eventual domain sharding.</p> +</div> + +<p>As an HTTP/1.x connection is serializing requests, even without any ordering, it can't be optimal without large enough available bandwidth. As a solution, browsers open several connections to each domain, sending parallel requests. Default was once 2 to 3 connections, but this has now increased to a more common use of 6 parallel connections. There is a risk of triggering <a href="/en-US/docs/Glossary/DOS_attack">DoS</a> protection on the server side if attempting more than this number.</p> + +<p>หากเซิร์ฟเวอร์ต้องการให้เว็บไซต์หรือแอปพลิเคชันตอบสนองเร็วขึ้นเซิร์ฟเวอร์อาจบังคับให้เปิดการเชื่อมต่อเพิ่มเติม ตัวอย่างเช่นแทนที่จะมีทรัพยากรทั้งหมดในโดเมนเดียวกันพูดก็อาจแบ่งมากกว่าหลายโดเมน,<code>www.example.com</code> , , แต่ละโดเมนเหล่านี้แก้ไขไปยังเซิร์ฟเวอร์<em>เดียวกัน</em>และเว็บเบราว์เซอร์จะเปิดการเชื่อมต่อ 6 รายการให้กับแต่ละโดเมน(ในตัวอย่างของเราเพิ่มการเชื่อมต่อเป็น 18) เทคนิคนี้เรียกว่าsharding<em> โดเมน</em><code>www1.example.com</code><code>www2.example.com</code><code>www3.example.com</code></p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/13783/HTTPSharding.png" style="height: 727px; width: 463px;"></p> + +<h2 id="สรุป">สรุป</h2> + +<p>การจัดการการเชื่อมต่อที่ได้รับการปรับปรุงช่วยเพิ่มประสิทธิภาพใน HTTP ได้มาก ด้วย HTTP / 1.1 หรือ HTTP / 1.0 การใช้การเชื่อมต่อแบบต่อเนื่องอย่างน้อยก็จนกว่าจะไม่มีการใช้งานจะนำไปสู่ประสิทธิภาพที่ดีที่สุด อย่างไรก็ตามความล้มเหลวของการวางท่อนำไปสู่การออกแบบรูปแบบการจัดการการเชื่อมต่อที่เหนือกว่าซึ่งรวมอยู่ใน HTTP / 2</p> diff --git a/files/my/web/http/index.html b/files/my/web/http/index.html new file mode 100644 index 0000000000..6e893c3ced --- /dev/null +++ b/files/my/web/http/index.html @@ -0,0 +1,90 @@ +--- +title: HTTP +slug: Web/HTTP +tags: + - HTTP + - Hypertext + - NeedsTranslation + - Reference + - TCP/IP + - TopicStub + - Web + - Web Development + - 'l10n:priority' +translation_of: Web/HTTP +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary"><strong><dfn>Hypertext Transfer Protocol (HTTP)</dfn></strong> is an <a href="https://en.wikipedia.org/wiki/Application_Layer">application-layer</a> protocol for transmitting hypermedia documents, such as HTML. It was designed for communication between web browsers and web servers, but it can also be used for other purposes. HTTP follows a classical <a href="https://en.wikipedia.org/wiki/Client%E2%80%93server_model">client-server model</a>, with a client opening a connection to make a request, then waiting until it receives a response. HTTP is a <a href="https://en.wikipedia.org/wiki/Stateless_protocol">stateless protocol</a>, meaning that the server does not keep any data (state) between two requests. Though often based on a TCP/IP layer, it can be used on any reliable <a href="https://en.wikipedia.org/wiki/Transport_Layer">transport layer</a>, that is, a protocol that doesn't lose messages silently like UDP does. <a href="https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol">RUDP</a> — the reliable update of UDP — is a suitable alternative.</p> + +<div class="column-container"> +<div class="column-half"> +<h2 id="Tutorials">Tutorials</h2> + +<p>Learn how to use HTTP with guides and tutorials.</p> + +<dl> + <dt><a href="/en-US/docs/Web/HTTP/Overview">Overview of HTTP</a></dt> + <dd>The basic features of the client-server protocol: what it can do and its intended uses.</dd> + <dt><a href="/en-US/docs/Web/HTTP/Caching">HTTP Cache</a></dt> + <dd>Caching is very important for fast Web sites. This article describes different methods of caching and how to use HTTP Headers to control them.</dd> + <dt><a href="/en-US/docs/Web/HTTP/Cookies">HTTP Cookies</a></dt> + <dd>How cookies work is defined by <a href="https://tools.ietf.org/html/rfc6265">RFC 6265</a>. When serving an HTTP request, a server can send a <code>Set-Cookie</code> HTTP header with the response. The client then returns the cookie's value with every request to the same server in the form of a <code>Cookie</code> request header. The cookie can also be set to expire on a certain date, or restricted to a specific domain and path.</dd> + <dt><a href="/en-US/docs/Web/HTTP/CORS">Cross-Origin Resource Sharing (CORS)</a></dt> + <dd><strong>Cross-site HTTP requests</strong> are HTTP requests for resources from a <strong>different domain</strong> than the domain of the resource making the request. For instance, an HTML page from Domain A (<code>http://domaina.example/</code>) makes a request for an image on Domain B (<code>http://domainb.foo/image.jpg</code>) via the <code>img</code> element. Web pages today very commonly load cross-site resources, including CSS stylesheets, images, scripts, and other resources. CORS allows web developers to control how their site reacts to cross-site requests.</dd> +</dl> + +<dl> + <dt><a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP">Evolution of HTTP</a></dt> + <dd>A brief description of the changes between the early versions of HTTP, to the modern HTTP/2, the emergent HTTP/3 and beyond.</dd> + <dt><a href="https://wiki.mozilla.org/Security/Guidelines/Web_Security">Mozilla web security guidelines</a></dt> + <dd>A collection of tips to help operational teams with creating secure web applications.</dd> +</dl> + +<dl> + <dt><a href="/en-US/docs/Web/HTTP/Messages">HTTP Messages</a></dt> + <dd>Describes the type and structure of the different kind of messages of HTTP/1.x and HTTP/2.</dd> + <dt><a href="/en-US/docs/Web/HTTP/Session">A typical HTTP session</a></dt> + <dd>Shows and explains the flow of a usual HTTP session.</dd> + <dt><a href="/en-US/docs/Web/HTTP/Connection_management_in_HTTP_1.x">Connection management in HTTP/1.x</a></dt> + <dd>Describes the three connection management models available in HTTP/1.x, their strengths, and their weaknesses.</dd> +</dl> +</div> + +<div class="column-half"> +<h2 id="Reference">Reference</h2> + +<p>Browse through detailed HTTP reference documentation.</p> + +<dl> + <dt><a href="/en-US/docs/Web/HTTP/Headers">HTTP Headers</a></dt> + <dd>HTTP message headers are used to describe a resource, or the behavior of the server or the client. Custom proprietary headers can be added using the <code>X-</code> prefix; others in an <a href="https://www.iana.org/assignments/message-headers/message-headers.xhtml#perm-headers">IANA registry</a>, whose original content was defined in <a href="https://tools.ietf.org/html/rfc4229">RFC 4229</a>. IANA also maintains a <a href="https://www.iana.org/assignments/message-headers/message-headers.xhtml#prov-headers">registry of proposed new HTTP message headers</a>.</dd> + <dt><a href="/en-US/docs/Web/HTTP/Methods">HTTP Request Methods</a></dt> + <dd>The different operations that can be done with HTTP: {{HTTPMethod("GET")}}, {{HTTPMethod("POST")}}, and also less common requests like {{HTTPMethod("OPTIONS")}}, {{HTTPMethod("DELETE")}}, or {{HTTPMethod("TRACE")}}.</dd> + <dt><a href="/en-US/docs/Web/HTTP/Response_codes">HTTP Status Response Codes</a></dt> + <dd>HTTP response codes indicate whether a specific HTTP request has been successfully completed. Responses are grouped in five classes: informational responses, successful responses, redirections, client errors, and servers errors.</dd> +</dl> + +<dl> + <dt><a href="/en-US/docs/Web/HTTP/Headers/Content-Security-Policy">CSP directives</a></dt> + <dd>The {{HTTPHeader("Content-Security-Policy")}} response header fields allows web site administrators to control resources the user agent is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints.</dd> +</dl> + +<h2 id="Tools_resources">Tools & resources</h2> + +<p>Helpful tools and resources for understanding and debugging HTTP.</p> + +<dl> + <dt><a href="/en-US/docs/Tools">Firefox Developer Tools</a></dt> + <dd><a href="/en-US/docs/Tools/Network_Monitor">Network monitor</a></dd> + <dt><a href="https://observatory.mozilla.org/">Mozilla Observatory</a></dt> + <dd> + <p>A project designed to help developers, system administrators, and security professionals configure their sites safely and securely.</p> + </dd> + <dt><a class="external" href="https://redbot.org/">RedBot</a></dt> + <dd>Tools to check your cache-related headers</dd> + <dt><a href="https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/">How Browsers Work</a></dt> + <dd>A very comprehensive article on browser internals and request flow through HTTP protocol. A MUST-READ for any web developer.</dd> +</dl> +</div> +</div> |