diff options
Diffstat (limited to 'files/ko/web/http/overview/index.html')
| -rw-r--r-- | files/ko/web/http/overview/index.html | 179 |
1 files changed, 179 insertions, 0 deletions
diff --git a/files/ko/web/http/overview/index.html b/files/ko/web/http/overview/index.html new file mode 100644 index 0000000000..f353394867 --- /dev/null +++ b/files/ko/web/http/overview/index.html @@ -0,0 +1,179 @@ +--- +title: HTTP 개요 +slug: Web/HTTP/Overview +tags: + - HTTP + - Overview + - WebMechanics + - 'l10n:priority' +translation_of: Web/HTTP/Overview +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary"><strong>HTTP는 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 </strong>{{glossary("protocol", "프로토콜")}}입니다. HTTP는 웹에서 이루어지는 모든 데이터 교환의 기초이며, 클라이언트-서버 프로토콜이기도 합니다. 클라이언트-서버 프로토콜이란 (보통 웹브라우저인) 수신자 측에 의해 요청이 초기화되는 프로토콜을 의미합니다. 하나의 완전한 문서는 텍스트, 레이아웃 설명, 이미지, 비디오, 스크립트 등 불러온(fetched) 하위 문서들로 재구성됩니다.</p> + +<p><img alt="A Web document is the composition of different resources" src="https://mdn.mozillademos.org/files/13677/Fetching_a_page.png" style="height: 319px; width: 545px;"></p> + +<p>클라이언트와 서버들은 (데이터 스트림과 대조적으로) 개별적인 메시지 교환에 의해 통신합니다. 보통 브라우저인 클라이언트에 의해 전송되는 메시지를 <em>요청(requests)이</em>라고 부르며, 그에 대해 서버에서 응답으로 전송되는 메시지를 응답(<em>responses)이</em>라고 부릅니다.</p> + +<p><img alt="HTTP as an application layer protocol, on top of TCP (transport layer) and IP (network layer) and below the presentation layer." src="https://mdn.mozillademos.org/files/13673/HTTP%20&%20layers.png" style="float: left; height: 299px; padding-bottom: 15px; padding-right: 20px; width: 418px;">1990년대 초에 설계된 HTTP는 거듭하여 진화해온 확장 가능한 프로토콜입니다. HTTP는 애플리케이션 계층의 프로토콜로, 신뢰 가능한 전송 프로토콜이라면 이론상으로는 무엇이든 사용할 수 있으나 {{glossary("TCP")}} 혹은 암호화된 TCP 연결인 {{glossary("TLS")}}를 통해 전송됩니다. HTTP의 확장성 덕분에, 오늘날 하이퍼텍스트 문서 뿐만 아니라 이미지와 비디오 혹은 HTML 폼 결과와 같은 내용을 서버로 포스트(POST)하기 위해서도 사용됩니다. HTTP는 또한 필요할 때마다 웹 페이지를 갱신하기 위해 문서의 일부를 가져오는데 사용될 수도 있습니다.</p> + +<h2 id="HTTP_기반_시스템의_구성요소">HTTP 기반 시스템의 구성요소</h2> + +<p>HTTP는 클라이언트-서버 프로토콜입니다. 요청은 하나의 개체, 사용자 에이전트(또는 그것을 대신하는 프록시)에 의해 전송됩니다. 대부분의 경우, 사용자 에이전트는 브라우저지만, 무엇이든 될 수 있습니다. 예를 들어, 검색 엔진 인덱스를 채워넣고 유지하기 위해 웹을 돌아다니는 로봇이 그러한 경우입니다.</p> + +<p>각각의 개별적인 요청들은 서버로 보내지며, 서버는 요청을 처리하고 <em>response</em>라고 불리는 응답을 제공합니다. 이 요청과 응답 사이에는 여러 개체들이 있는데, 예를 들면 다양한 작업을 수행하는 게이트웨이 또는 {{glossary("Cache", "캐시")}} 역할을 하는 {{glossary("Proxy", "프록시")}} 등이 있습니다.</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/13679/Client-server-chain.png" style="height: 121px; width: 819px;"></p> + +<p>실제로는 브라우저와 요청을 처리하는 서버 사이에는 좀 더 많은 컴퓨터들이 존재합니다: 라우터, 모뎀 등이 있죠. 웹의 계층적인 설계 덕분에, 이들은 네트워크와 전송 계층 내로 숨겨집니다. HTTP은 애플리케이션 계층의 최상위에 있습니다. 네트워크 문제를 진단하는 것도 중요하지만, 기본 레이어들은 HTTP의 명세와는 거의 관련이 없습니다.</p> + +<h3 id="클라이언트_사용자_에이전트">클라이언트: 사용자 에이전트</h3> + +<p>사용자 에이전트는 사용자를 대신하여 동작하는 모든 도구입니다. 이 역할은 주로 브라우저에 의해 수행됩니다; 엔지니어들과 자신들의 애플리케이션을 디버그하는 웹 개발자들이 사용하는 프로그램들은 예외입니다.</p> + +<p>브라우저는 <strong>항상</strong> 요청을 보내는 개체입니다. 그것은 결코 서버가 될 수 없습니다(수년에 걸쳐 서버 초기화된 메시지를 시뮬레이션하기 위해 몇 가지 메커니즘이 추가되어 왔지만).</p> + +<p>웹 페이지를 표시하기 위해, 브라우저는 페이지의 HTML 문서를 가져오기 위한 요청을 전송한 뒤, 파일을 구문 분석하여 실행해야 할 스크립트 그리고 페이지 내 포함된 하위 리소스들(보통 이미지와 비디오)을 잘 표시하기 위한 레이아웃 정보(CSS)에 대응하는 추가적인 요청들을 가져옵니다. 그런 뒤에 브라우저는 완전한 문서인 웹 페이지를 표시하기 위해 그런 리소스들을 혼합합니다. 브라우저에 의해 실행된 스크립트는 이후 단계에서 좀 더 많은 리소스들을 가져올 수 있으며 브라우저는 그에 따라 웹 페이지를 갱신하게 됩니다.</p> + +<p>웹 페이지는 하이퍼텍스트 문서로, 표시된 텍스트의 일부는 사용자가 사용자 에이전트를 제어하고 웹을 돌아다닐 수 있도록 새로운 웹 페이지를 가져오기 위해 실행(보통 마우스 클릭에 의해)될 수 있는 링크임을 뜻합니다. 브라우저는 HTTP 요청 내에서 이런 지시 사항들을 변환하고 HTTP 응답을 해석하여 사용자에게 명확한 응답을 표시합니다.</p> + +<h3 id="웹_서버">웹 서버</h3> + +<p>통신 채널의 반대편에는 클라이언트에 의한 요청에 대한 문서를 <em>제공</em>하는 서버가 존재합니다. 서버는 사실 상 논리적으로 단일 기계입니다.이는 로드(로드 밸런싱) 혹은 그때 그때 다른 컴퓨터(캐시, DB 서버, e-커머스 서버 등과 같은)들의 정보를 얻고 완전하게 혹은 부분적으로 문서를 생성하는 소프트웨어의 복잡한 부분을 공유하는 서버들의 집합일 수도 있기 때문입니다.</p> + +<p>서버는 반드시 단일 머신일 필요는 없지만, 여러 개의 서버를 동일한 머신 위에서 호스팅 할 수는 있습니다. HTTP/1.1과 {{HTTPHeader("Host")}} 헤더를 이용하여, 동일한 IP 주소를 공유할 수도 있습니다.</p> + +<h3 id="프록시">프록시</h3> + +<p>웹 브라우저와 서버 사이에서는 수많은 컴퓨터와 머신이 HTTP 메시지를 이어 받고 전달합니다. 여러 계층으로 이루어진 웹 스택 구조에서 이러한 컴퓨터/머신들은 대부분은 전송, 네트워크 혹은 물리 계층에서 동작하며, 성능에 상당히 큰 영향을 주지만 HTTP 계층에서는 이들이 어떻게 동작하는지 눈에 보이지 않습니다. 이러한 컴퓨터/머신 중에서도 애플리케이션 계층에서 동작하는 것들을 일반적으로 <strong>프록시</strong>라고 부릅니다. 프록시는 눈에 보이거나 그렇지 않을 수도 있으며(프록시를 통해 요청이 변경되거나 변경되지 않는 경우를 말함) 다양한 기능들을 수행할 수 있습니다:</p> + +<ul> + <li>캐싱 (캐시는 공개 또는 비공개가 될 수 있습니다 (예: 브라우저 캐시))</li> + <li>필터링 (바이러스 백신 스캔, 유해 컨텐츠 차단(자녀 보호) 기능)</li> + <li>로드 밸런싱 (여러 서버들이 서로 다른 요청을 처리하도록 허용)</li> + <li>인증 (다양한 리소스에 대한 접근 제어)</li> + <li>로깅 (이력 정보를 저장)</li> +</ul> + +<h2 id="HTTP의_기초적인_측면">HTTP의 기초적인 측면</h2> + +<h3 id="HTTP은_간단합니다">HTTP은 간단합니다</h3> + +<p>HTTP는 사람이 읽을 수 있으며 간단하게 고안되었습니다. 심지어 HTTP/2가 다소 더 복잡해졌지만 여전히 HTTP 메세지를 프레임별로 캡슐화하여 간결함을 유지하였습니다. HTTP 메시지들은 사람이 읽고 이해할 수 있어, 테스트하기 쉽고 초심자의 진입장벽을 낮췄습니다.</p> + +<h3 id="HTTP은_확장_가능합니다">HTTP은 확장 가능합니다</h3> + +<p>HTTP/1.0에서 소개된, <a href="/en-US/docs/Web/HTTP/Headers">HTTP 헤더</a>는 HTTP를 확장하고 실험하기 쉽게 만들어주었습니다. 클라이언트와 서버가 새로운 헤더의 시맨틱에 대해 간단한 합의만 한다면, 언제든지 새로운 기능을 추가할 수 있습니다.</p> + +<h3 id="HTTP은_상태가_없지만_세션은_있습니다">HTTP은 상태가 없지만, 세션은 있습니다</h3> + +<p>HTTP는 상태를 저장하지 않습니다(Stateless). 동일한 연결 상에서 연속하여 전달된 두 개의 요청 사이에는 연결고리가 없습니다. 이는 e-커머스 쇼핑 바구니처럼, 일관된 방식으로 사용자가 페이지와 상호작용하길 원할 때 문제가 됩니다. 하지만, HTTP의 핵심은 상태가 없는 것이지만 HTTP 쿠키는 상태가 있는 세션을 만들도록 해줍니다.<br> + 헤더 확장성을 사용하여, 동일한 컨텍스트 또는 동일한 상태를 공유하기 위해 각각의 요청들에 세션을 만들도록 HTTP 쿠키가 추가됩니다.</p> + +<h3 id="HTTP와_연결">HTTP와 연결</h3> + +<p>연결은 전송 계층에서 제어되므로 근본적으로 HTTP 영역 밖입니다. HTTP는 연결될 수 있도록 하는 근본적인 전송 프로토콜을 요구하지 않습니다; 다만 그저 신뢰할 수 있거나 메시지 손실이 없는(최소한의 오류는 표시) 연결을 요구할 뿐입니다. 인터넷 상의 가장 일반적인 두 개의 전송 프로토콜 중에서 TCP는 신뢰할 수 있으며 UDP는 그렇지 않습니다. 그러므로 HTTP는 연결이 필수는 아니지만 연결 기반인 TCP 표준에 의존합니다.</p> + +<p>클라이언트와 서버가 HTTP를 요청/응답으로 교환하기 전에 여러 왕복이 필요한 프로세스인 TCP 연결을 설정해야 합니다. HTTP/1.0의 기본 동작은 각 요청/응답에 대해 별도의 TCP 연결을 여는 것입니다. 이 동작은 여러 요청을 연속해서 보내는 경우에는 단일 TCP 연결을 공유하는 것보다 효율적이지 못합니다.</p> + +<p>이러한 결함을 개선하기 위해, HTTP/1.1은 (구현하기 어렵다고 입증된) 파이프라이닝 개념과 지속적인 연결의 개념을 도입했습니다: 기본적인 TCP 연결은 {{HTTPHeader("Connection")}} 헤더를 사용해 부분적으로 제어할 수 있습니다. HTTP/2는 연결을 좀 더 지속되고 효율적으로 유지하는데 도움이 되도록, 단일 연결 상에서 메시지를 다중 전송(multiplex)하여 한 걸음 더 나아갔습니다.</p> + +<p>HTTP에 더 알맞은 좀 더 나은 전송 프로토콜을 설계하는 실험이 진행 중에 있습니다. 예를 들어, 구글은 좀 더 신뢰성있고 효율적인 전송 프로토콜을 제공하기 위해 UDP기반의 <a href="https://en.wikipedia.org/wiki/QUIC">QUIC</a>를 실험 중에 있습니다.</p> + +<h2 id="HTTP로_제어할_수_있는_것">HTTP로 제어할 수 있는 것</h2> + +<p>HTTP의 확장 가능한 특성은 수년 간에 걸쳐 웹의 점점 더 많은 기능들을 제어하도록 허용되어 왔습니다. 캐시 혹은 인증 메서드는 HTTP에 초기부터 제어해왔던 기능이며, 반면에 <code>origin</code> <em>제약사항</em>을 완화시키는 조치는 2010년에 들어서 추가되었습니다.</p> + +<p>다음은 HTTP 사용하여 제어 가능한 일반적인 기능 목록입니다.</p> + +<ul> + <li><a href="/ko/docs/Web/HTTP/Caching">캐시</a><br> + HTTP로 문서가 캐시되는 방식을 제어할 수 있습니다. 서버는 캐시 대상과 기간을 프록시와 클라이언트에 지시할 수 있고 클라이언트는 저장된 문서를 무시하라고 중간 캐시 프록시에게 지시할 수 있습니다.</li> + <li><em>origin 제약사항을 완화하기</em><br> + 스누핑과 다른 프라이버시 침해를 막기 위해, 브라우저는 웹 사이트 간의 엄격한 분리를 강제합니다. <strong>동일한 origin</strong>으로부터 온 페이지만이 웹 페이지의 전체 정보에 접근할 수 있죠. 그런 제약 사항은 서버에 부담이 되지만, HTTP 헤더를 통해 그것을 완화시킬 수 있습니다. 그런 덕분에 문서는 다른 도메인으로부터 전달된 정보를 패치워크할 수 있습니다(그렇게 하려면 어떤 경우에 보안과 관련된 사항이 있을 수도 있습니다).</li> + <li><em>인증</em><br> + 어떤 페이지들은 보호되어 오로지 특정 사용자만이 그것에 접근할 수도 있습니다. 기본 인증은 HTTP를 통해 {{HTTPHeader("WWW-Authenticate")}} 또는 유사한 헤더를 사용해 제공되거나, <a href="/ko/docs/Web/HTTP/Cookies">HTTP 쿠키</a>를 사용해 특정 세션을 설정하여 이루어질 수도 있습니다.</li> + <li><a href="/ko/docs/Web/HTTP/Proxy_servers_and_tunneling">프록시와 터널링</a><br> + 서버 혹은 클라이언트 혹은 그 둘 모두는 종종 인트라넷에 위치하며 다른 개체들에게 그들의 실제 주소를 숨기기도 합니다. HTTP 요청은 네트워크 장벽을 가로지르기 위해 프록시를 통해 나가게 되죠. 모든 프록시가 HTTP 프록시는 아닙니다. 예를 들면 SOCKS 프로토콜은 좀 더 저수준에서 동작합니다. FTP와 같은 다른 프로토콜도 이 프록시를 통해 처리될 수 있습니다.</li> + <li><em>세션</em><br> + 쿠키 사용은 서버 상태를 요청과 연결하도록 해줍니다. 이것은 HTTP가 기본적으로 상태없는 프로토콜임에도 세션을 만들어주는 계기가 됩니다. 이것은 e-커머스 쇼핑 바구니를 위해서 유용할 뿐만 아니라 사용자 구성을 허용하는 모든 사이트에 대해서 유용합니다.</li> +</ul> + +<h2 id="HTTP_흐름">HTTP 흐름</h2> + +<p>클라이언트가 서버와 통신하고자 할 때, 최종 서버가 됐든 중간 프록시가 됐든, 다음 단계의 과정을 수행합니다:</p> + +<ol> + <li>TCP 연결을 엽니다:TCP 연결은 요청을 보내거나(혹은 여러개의 요청) 응답을 받는데 사용됩니다. 클라이언트는 새 연결을 열거나, 기존 연결을 재사용하거나, 서버에 대한 여러 TCP 연결을 열 수 있습니다.</li> + <li>HTTP 메시지를 전송합니다: HTTP 메시지(HTTP/2 이전의)는 인간이 읽을 수 있습니다. HTTP/2에서는 이런 간단한 메시지가 프레임 속으로 캡슐화되어, 직접 읽는게 불가능하지만 원칙은 동일합니다. + <pre class="line-numbers language-html notranslate"><code class="language-html">GET / HTTP/1.1 +Host: developer.mozilla.org +Accept-Language: fr</code></pre> + </li> + <li>서버에 의해 전송된 응답을 읽어들입니다: + <pre class="line-numbers language-html notranslate"><code class="language-html">HTTP/1.1 200 OK +Date: Sat, 09 Oct 2010 14:28:02 GMT +Server: Apache +Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT +ETag: "51142bc1-7449-479b075b2891b" +Accept-Ranges: bytes +Content-Length: 29769 +Content-Type: text/html + +<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)</code></pre> + </li> + <li>연결을 닫거나 다른 요청들을 위해 재사용합니다.</li> +</ol> + +<p>HTTP 파이프라이닝이 활성화되면, 첫번째 응답을 완전히 수신할 때까지 기다리지 않고 여러 요청을 보낼 수 있습니다. HTTP 파이프라이닝은 오래된 소프트웨어와 최신 버전이 공존하고 있는, 기존의 네트워크 상에서 구현하기 어렵다는게 입증되었으며, 프레임안에서 보다 활발한 다중 요청을 보내는 HTTP/2로 교체되고 있습니다.</p> + +<h2 id="HTTP_메시지">HTTP 메시지</h2> + +<p>HTTP/1.1와 초기 HTTP 메시지는 사람이 읽을 수 있습니다. HTTP/2에서, 이 메시지들은 새로운 이진 구조인 프레임 안으로 임베드되어, 헤더의 압축과 다중화와 같은 최적화를 가능케 합니다. 본래의 HTTP 메시지의 일부분만이 이 버전의 HTTP 내에서 전송된다고 할지라도, 각 메시지의 의미들은 변화하지 않으며 클라이언트는 본래의 HTTP/1.1 요청을 (가상으로) 재구성합니다. 그러므로 HTTP/1.1 포맷 내에서 HTTP/2를 이해하는 것은 여전히 유용합니다.</p> + +<p>HTTP 메시지의 두 가지 타입인 요청(requests)과 응답(responses)은 각자의 특성있는 형식을 가지고 있습니다.</p> + +<h3 id="요청">요청</h3> + +<p>HTTP 요청의 예:</p> + +<p><img alt="A basic HTTP request" src="https://mdn.mozillademos.org/files/13687/HTTP_Request.png" style="height: 336px; width: 693px;"></p> + +<p>요청은 다음의 요소들로 구성됩니다:</p> + +<ul> + <li>HTTP <a href="/ko/docs/Web/HTTP/Methods">메서드</a>, 보통 클라이언트가 수행하고자 하는 동작을 정의한 {{HTTPMethod("GET")}}, {{HTTPMethod("POST")}} 같은 동사나 {{HTTPMethod("OPTIONS")}}나 {{HTTPMethod("HEAD")}}와 같은 명사입니다. 일반적으로, 클라이언트는 리소스를 가져오거나(<code>GET</code>을 사용하여) <a href="/en-US/docs/Web/Guide/HTML/Forms">HTML 폼</a>의 데이터를 전송(<code>POST</code>를 사용하여)하려고 하지만, 다른 경우에는 다른 동작이 요구될 수도 있습니다.</li> + <li>가져오려는 리소스의 경로; 예를 들면 {{glossary("protocol", "프로토콜")}} (<code>http://</code>), {{glossary("domain", "도메인")}} (여기서는 <code>developer.mozilla.org</code>), 또는 TCP {{glossary("port", "포트")}} (여기서는 <code>80</code>)인 요소들을 제거한 리소스의 URL입니다.</li> + <li>HTTP 프로토콜의 버전.</li> + <li>서버에 대한 추가 정보를 전달하는 선택적 <a href="/en-US/docs/Web/HTTP/Headers">헤더들</a>.</li> + <li><code>POST</code>와 같은 몇 가지 메서드를 위한, 전송된 리소스를 포함하는 응답의 본문과 유사한 본문.</li> +</ul> + +<h3 id="응답">응답</h3> + +<p>응답의 예:</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/13691/HTTP_Response.png" style="height: 494px; width: 758px;"></p> + +<p>응답은 다음의 요소들로 구성됩니다:</p> + +<ul> + <li>HTTP 프로토콜의 버전.</li> + <li>요청의 성공 여부와, 그 이유를 나타내는 <a href="/en-US/docs/Web/HTTP/Status">상태 코드</a>.</li> + <li>아무런 영향력이 없는, 상태 코드의 짧은 설명을 나타내는 상태 메시지.</li> + <li>요청 헤더와 비슷한, HTTP <a href="/en-US/docs/Web/HTTP/Headers">헤더들</a>.</li> + <li>선택 사항으로, 가져온 리소스가 포함되는 본문.</li> +</ul> + +<h2 id="HTTP_기반_API">HTTP 기반 API</h2> + +<p>HTTP 기반으로 가장 일반적으로 사용된 API는 {{Glossary("user agent")}}와 서버간에 데이터를 교환하는데 사용될 수 있는 {{domxref("XMLHttpRequest")}} API 입니다. 최신 {{domxref("Fetch API")}}는 보다 강력하고 유연한 기능을 제공합니다.</p> + +<p>또 다른 API인 <a href="/ko/docs/Web/API/Server-sent_events">서버-전송 이벤트</a>는 서버가 전송 메커니즘으로 HTTP를 사용하여, 클라이언트로 이벤트를 보낼 수 있도록 하는 단방향 서비스입니다. 클라이언트는 {{domxref("EventSource")}} 인터페이스를 사용하여, 연결을 맺고 이벤트 핸들러를 설정합니다. 클라이언트 브라우저는 HTTP 스트림으로 도착한 메시지를 적절한 {{domxref("Event")}} 객체로 자동 변환하여, 알려진 경우 해당 이벤트 {{domxref("Event.type", "type")}}에 대해 등록된 이벤트 핸들러로 전달하거나 또는 특정 유형의 이벤트가 설정되지 않은 경우에는 {{domxref("EventSource.onmessage", "onmessage")}} 이벤트 핸들러로 전달합니다.</p> + +<h2 id="결론">결론</h2> + +<p>HTTP는 사용이 쉬운 확장 가능한 프로토콜입니다. 헤더를 쉽게 추가하는 능력을 지닌 클라이언트-서버 구조는 HTTP가 웹의 확장된 수용력과 함께 발전할 수 있게 합니다.</p> + +<p>HTTP/2가 성능 향상을 위해 HTTP 메시지를 프레임 내로 임베드하여 약간의 복잡함을 더했을지라도, 애플리케이션의 관점에서 볼 때, 메시지의 기본적인 구조는 HTTP/1.0이 릴리즈된 이후와 동일합니다. 세션의 흐름은 여전히 단순하여, 간단한 <a href="/ko/docs/Tools/Network_Monitor">HTTP 메시지 모니터</a>를 이용한 조사와 디버그를 가능하게 해줍니다.</p> |