이 훈련에서는 웹(WEB)에 관한 기초 지식과 웹에서 사용되는 HTTP 프로토콜에 대해 학습합니다.



웹이란?

 웹은 인터넷의 하위 개념인 World Wide Web(일반적으로 WWW로 쓰임)을 말하며, 특수한 형식의 문서(예:HTML)나 이미지, 동영상 등의 웹 리소스를 인터넷과 하이퍼 텍스트를 통해 서로 연결한 시스템입니다. 

흔히 사람들은 웹사이트를 탐색하는 행위를 일컬어 "인터넷을 한다"는 등 웹과 인터넷을 동일한 개념으로 혼용하곤 하지만, 사실 인터넷과 웹은 서로 다른 개념입니다. 인터넷이란 TCP/IP 프로토콜을 통해 연결되어 있는 대규모 글로벌 네트워크입니다. 인터넷과 하이퍼 텍스트는 웹이 생기기 이전부터 이미 존재했었으나 그 누구도 이 기술을 활용해 문서와 문서를 연결하는 방법을 생각하지 못했고, 1989년경 팀 버너스 리(Tim Berners-Lee)는 과학자들이 데이터를 보다 쉬운 방법으로 공유할 수 있도록 웹을 발명했습니다. 웹의 탄생과 발전으로 인해 세상의 모든 사람이 서로 연결되고, 정보를 공유, 소통할 수 있게 되었습니다.

웹 리소스란?

 웹을 통해 요청되는 대상을 웹 리소스(Web Resource)라고 하며 웹에서 사용되는 모든 컨텐츠를 말합니다. 웹 리소스에는 HTML, CSS, JAVASCRIPT, 텍스트, 이미지 등이 있습니다.

웹 리소스 식별하기

 웹 리소스는 URI를 통해 식별됩니다.

URI(Uniform Resource Identifier)는 통합 리소스 식별자이며, 앞서 말했듯 URI란 인터넷상에 있는 웹 리소스를 고유하게 식별할 수 있는 식별자입니다.

여러분은 이미 URL이라는 말은 익히 들어 보았을 것 입니다. URI와 URL은 보통 의미의 구분없이 사용되곤 하지만 두 용어에는 약간의 차이가 있습니다.

URL(Unifrom Resource Locator)은 인터넷상의 리소스의 위치를 나타냅니다. URL에서의 리소스는 하나의 파일을 의미하며, 바꿔 말하면 웹 상에서 접근할 수 있는 문서, 이미지, 동영상 등의 파일의 위치를 말합니다.

사용자 프로필 사진(myphoto.jpg)을 볼 수 있는 아래와 같은 형식은 URL이며 동시에 URI도 될 수 있습니다.

https://www.bugbountyclub/profile/myphoto.jpg 

그럼 아래와 같이 PHP로 구현된 블로그의 특정 게시글을 볼 수 있는 형식은 어떨까요?

https://www.bugbountyclub.com/blog.php?category_no=1&article_no=1 

위의 형식에서는 URL과 URI가 다른 의미로 사용됩니다.

여기서 URL은 http://www.bugbountyclub.com/blog.php라는 PHP 파일까지입니다. 그리고 blog.php 파일을 통해 백엔드 데이터 저장소에 저장된 특정한 게시글을 식별하기 위해 사용된 ?category_no=1&article_no=1(이 부분을 쿼리스트링이라고 합니다.)까지를 통틀어 URI라고 합니다. 

URL과 URI

 즉, URL은 URI에 속하는 형태 중 하나로, URI가 더 큰 개념이라고 할 수 있습니다. 

이와 같이 URL과 URI의 의미는 약간의 차이가 있습니다. 이 글에서는 URI라는 용어를 사용하겠지만 어려분들께서는 반드시 구분해서 사용할 자리가 아니라면 그냥 URL을 사용하셔도 무방합니다.  

URI 구조는 어떻게 생겼을까?

 여러분은 웹을 통해 리소스를 식별하고 요청하기 위해서는 URI가 사용된다는 것을 알았습니다. 따라서 여러분은 URI의 구조가 어떻게 생겼는지 이해하고 계셔야 합니다.

URI는 일반적으로 아래의 형식에 따라 선택적으로 사용됩니다. 

Scheme://Username:Password@Host:Port/Path?Query#Fragment

각 구성요소에 대한 의미는 다음과 같습니다.

• Scheme: 어떤 프로토콜을 사용하여 리소스를 요청할지를 의미합니다. 웹인 경우 http, https를 사용하며, ftp, file 등의 프로토콜을 사용하기도 합니다.
• Username: 요청하는 리소스가 인증이 요구되는 경우 리소스에 접근하기 위한 사용자 이름을 의미합니다.
• Password: 요청하는 리소스가 인증이 요구되는 리소스인 경우 리소스에 접근하기 위한 사용자 패스워드를 의미합니다.
• Host: 클라이언트가 리소스를 요청할 대상 컴퓨터(서버)입니다.
• Port: 웹 서버의 특정 서비스에 접근하기 위한 포트번호를 의미합니다. 웹은 80이나 443 포트를 사용합니다.
• Path: 호스트상의 리소스의 경로를 의미합니다.
• Query: GET 요청에서 데이터를 웹 서버로 전달할 때 사용됩니다.
• Fragment: 하나의 HTML 페이지 내에서 특정 요소로 스크롤을 이동하기 위해 사용됩니다. 

다음은 위의 형식에 따라 URI를 구분한 예시입니다. 연보라색 음영 처리 부분을 구분자로 하여 각각의 파트가 구분되고 해석됩니다.

URI의 형식

웹의 동작 방식과 구성 요소

 사용자가 Bug Bounty Club 웹사이트를 방문하는 상황을 그림으로 살펴봅시다.

 사용자가 웹 브라우저의 주소표시줄에  URL(https://www.bugbountyclub.com)을 입력 후 이동하게 되면 위의 그림에는 표현되지 않았지만 웹 브라우저는 제일 먼저 DNS 서버로부터 입력된 웹 주소의 IP주소를 알아냅니다. 그리고 웹 브라우저는 HTTP를 통해 웹 서버에 웹 사이트의 사본을 요청하게 됩니다. 요청을 받은 웹 서버는 구동 중인 웹 애플리케이션에서 요청에 해당되는 웹 페이지(문서)를 찾아 웹 브라우저에게 응답으로 보내고, 응답을 받은 웹 브라우저는 웹 페이지를 브라우저에 표시하게 됩니다.

 여기서 웹을 구성하는 5가지 구성 요소를 확인해 볼 수 있습니다.

• 웹 클라이언트(Web Client): 요청을 하는 주체, 즉 사용자를 말합니다.
• 웹 브라우저(Web Browser): 사용자가 웹 서버에 요청을 보내기 위해 사용한 소프트웨어입니다.
• HTTP(Hyper Text Transper Protocol): 웹을 통한 정보 전송을 위한 통신 프로토콜(규약)입니다.
• 웹 서버(Web Server): 웹 브라우저의 요청에 해당되는 웹 페이지를 제공하는 주체입니다.
• 웹 애플리케이션(Web Application): 웹 브라우저를 통해 접근할 수 있는 응용 프로그램입니다.

 웹의 구성 요소에 대해 더 자세히 살펴 보겠습니다.

웹 클라이언트

웹 브라우저를 이용하여 요청을 하는 사용자 자체를 의미합니다.

웹 브라우저

위키백과에 따르면, 웹 브라우저의 정의는 다음과 같습니다.

"웹 브라우저(또는 브라우저)는 웹 상의 정보에 접근하기 위한 소프트웨어입니다. 사용자가 특정 웹사이트의 웹 페이지를 요청하면 웹 브라우저는 웹 서버로부터 필요한 컨텐츠를 받아서 사용자의 디바이스에 표시합니다.(이하 생략)"

즉, 웹사이트를 방문하여 문서를 검색하고, 웹사이트의 다양한 기능을 사용하기 위해서 사용되는 일종의 응용 프로그램입니다.

웹 브라우저의 종류로는 이 글을 작성하는 시점 기준으로 구글의 크롬(Chrome), 애플의 사파리(Safari), 마이크로소프트의 엣지(Edge), Opera(오페라) 등이 있으며, 이 중에서 현재 전 세계적으로 시장 점유율이 가장 높은 웹 브라우저는 구글의 크롬입니다. 

HTTP (Hyper Text Transfer Protocol)

 HTTP는 웹에서 HTML 문서를 주고 받기 위한 OSI 7 Layer상의 7계층(Application Layer)에 속하는 통신 프로토콜로, 웹의 핵심이 되는 통신 프로토콜입니다.  HTTP는 전통적인 클라이언트/서버 모델을 따르며, 메시지 기반의 요청(Request)과 응답(Response)을 통해 정보를 교환합니다.  또한, HTTP는 비상태성(Stateless), 비연결성(Connectionless)이라는 특징을 가지는데 다시 말해서 클라이언트의 요청에 서버가 응답을 보낸 후 연결을 유지하지 않고 종료시키며, 어떤 상태도 저장하지 않는다는 것을 말합니다.

HTTP/1.1

이런 특징으로 인해 웹 애플리케이션에서는 사용자 추적을 위해 세션(Session)과 쿠키(Cookie)라는 것을 사용하게 됩니다만, 이 부분은 추후 다루도록 하겠습니다. 

HTTP 요청

일반적인 HTTP 요청은 다음과 같이 요청 라인, 요청 헤더, 빈 줄, 메시지 바디.. 이렇게 총 네 가지로 나뉘어집니다.

HTTP 요청 메시지

요청 라인

 요청 라인은 최상위에 있는 줄이며, 아래 형식과 같이 공백문자(Space)로 구분된 요청 메소드(Request Method), 요청 URI(Request-URI), HTTP 버전(HTTP-Version)으로 구성됩니다.

요청 메소드{Space}요청 URI{Space}HTTP 버전

위에서 예시로 보여 준 HTTP 요청에서는 아래의 내용이 요청 라인이 됩니다.

POST /account HTTP/1.1

• POST: HTTP 요청 메소드
• /account: 요청 URI
• HTTP/1.1: HTTP 버전

HTTP 요청 메소드에는 다음 종류가 있습니다. 

• OPTIONS: 요청할 리소스에 알맞은 HTTP 요청 메소드를 알아내기 위해 사용됩니다. 서버는 Allow 헤더에 사용 가능한 헤더 목록을 나열하여 클라이언트에 응답합니다. 
• HEAD: GET 요청과 유사하지만 응답에 Body를 포함하지 않은 채로 응답합니다. 요청할 리소스가 존재하는지 사전에 알아보기 위해 사용됩니다.
• GET: 웹 서버상의 특정 리소스를 요청할 때 사용됩니다.(전송할 때 쓰이기도 합니다.) 
• POST: 웹 서버에 리소스를 전송(저장, 변경하는 등의 특정 행위) 할 때 사용됩니다. 주로 Form 양식에 사용됩니다. (요청할 때 쓰이기도 합니다.)
• PUT: 서버에 파일 등의 리소스를 업로드할 때 사용됩니다. 공격자가 서버에 악성 스크립트 파일을 업로드하기 위해 사용될 수 있습니다.
• DELETE: 서버의 특정 리소스를 삭제합니다.
• TRACE: 대상 리소스의 경로를 따라 메시지 루프백(loop-back) 테스트를 합니다. 요청을 그대로 반환합니다.
• CONNECT: 대상이 되는 서버와 터널을 맺습니다.

웹 애플리케이션에서 주로 사용되는 메소드는 GET과 POST입니다. 이 두 개의 메소드는 반드시 숙지하셔야 하며, GET과 POST 메소드에 대해 좀 더 살펴보도록 하겠습니다.

GET 요청

 예를 들어, Bug Bounty Club 블로그에 존재하는 특정 게시글을 조회하는 요청을 하게 되면 다음과 같은 요청이 웹 서버로 전송되게 됩니다. 다시 말해서 사용자가 웹 브라우저를 통해 https://www.bugbountyclub.com/blog?category_no=1&article_no=1 페이지를 방문한 경우입니다. 

GET /blog?category_no=1&article_no=1 HTTP/1.1
Host: www.bugbountyclub.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
...생략...

 위에서 배운 요청 라인의 내용을 보면 메소드는 GET이고, 요청 URI는 /blog?category_no=1&article_no=1, 그리고 HTTP 버전이 1.1인 것을 확인할 수 있습니다. 보시는 바와 같이 이 요청은 단순히 서버에 존재하는 리소스(게시글)를 읽기만 하면 되므로 GET 메소드를 사용하여 리소스를 가져오게 됩니다. 주목해야 할 점은 category_no=1&article_no=1이라는 리소스를 식별하기 위한 매개변수와 값(이를 쿼리 스트링Query String이라고 합니다.)이 요청 URI에 포함되어 있다는 점입니다. 쿼리스트링 앞에 위치한 ?는 쿼리스트링을 구분하기 위한 구분자이며, 쿼리스트링 내에서 사용된 &는 각각의 매개변수를 구분하기 위해 사용됩니다. 즉, 위 예시에서는 category_no와 article_no 두 개의 매개변수가 각각 1이라는 값으로 웹서버에 요청이 전송되게 됩니다. 그리고 한 가지 더 확인하실 수 있는 점은 요청 라인과 요청 헤더 영역 아래에 메시지 바디 영역이 없다는 것입니다. 

POST 요청

 사용자가 다음과 같이 폼 기반 로그인 방식이 구현된 웹사이트에 로그인하는 경우를 살펴봅시다.

 사용자가 로그인 폼에 로그인 아이디와 패스워드를 입력 후 Log In 버튼을 클릭하면 웹 브라우저는 다음과 같은 요청을 웹 서버로 전송합니다.

POST /login HTTP/1.1
Host: www.bugbountyclub.comUser-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Content-Type: application/x-www-form-urlencoded
Content-Length: 19
...생략...

id=foo&password=bar

 요청 라인을 보면 POST 메소드를 이용해 /login 페이지를 요청한다는 것을 알 수 있습니다. 물론 HTTP 버전은 1.1입니다. 위에서 살펴본 GET 요청과 다른 점은 id=foo&password=bar 라는 로그인 아이디와 패스워드에 해당하는 매개변수와 값이 제일 아래 줄의 메시지 바디 영역에 포함되어 있다는 점입니다. 그리고, 이 메시지 바디는 요청 라인과 요청 헤더 영역과 빈 줄(Empty line)으로 구분됨을 알 수 있습니다. 그리고 요청 헤더 영역의 굵은 글자로 되어 있는 Content-Type 헤더의 값이 application/x-www-form-urlencoded 라는 점을 기억 후 다음으로 넘어갑니다.

 POST 요청의 다른 형태도 있습니다. 일반적으로 폼 양식은 enctype 속성에 어떤 값이 주어지느냐에 따라 POST 요청의 형태가 달라집니다.

<form action="target" method="POST" enctype="some value">

 enctype 속성을 생략하면 기본적으로 먼저 살펴 본 형태로 요청이 전송되나, enctype="multipart/form-data"로 지정하는 경우에는 다음과 같은 형태의 POST 요청이 웹 서버로 전송됩니다. 비교를 위해 위에서 예시로 제시했던 동일한 로그인 페이지를 enctype="multipart/form-data"로 적용해봤습니다. 

POST /login HTTP/1.1
Host: www.bugbountyclub.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary4nAP0jkXBQK2Owkk
Content-Length: 6671
...생략...

------WebKitFormBoundary4nAP0jkXBQK2Owkk
Content-Disposition: form-data; name="id"

foo

------WebKitFormBoundary4nAP0jkXBQK2Owkk
Content-Disposition: form-data; name="password"

bar

------WebKitFormBoundary4nAP0jkXBQK2Owkk--

 Content-Type 헤더를 보시면 boundary에 일련의 값이 할당되어 있으며, 메시지 바디 영역의 매개변수들은 이 boundary을 통해 구분되는 것을 보실 수 있습니다. 이와 같은 형태는 파일을 업로드하는 경우 주로 사용됩니다. 

 웹 개발 시 주의하셔야 할 점은 민감한 정보가 웹 서버로 전송되는 경우에는 반드시 POST 메소드를 사용해야 합니다. 만일 위의 로그인 페이지를 GET 메소드로 구현하게 되면 사용자가 로그인을 할 때 아래와 같은 GET 요청이 발생하며 사용자의 로그인 아이디와 패스워드는 URL상에 그대로 노출되게 됩니다. 이와 같이 URL상에 노출된 정보는 얼마든지 악의적인 공격자에 의해 악용될 수 있습니다.

https://www.bugbountyclub.com/login?id=foo&password=bar

요청 헤더

 기본적으로 요청과 응답 모두 헤더를 통해 다양한 정보를 담고 있습니다. 요청과 응답에서 공통으로 사용되는 헤더들이 있기에 HTTP 응답까지 살펴본 후 한번에 확인해보겠습니다.

HTTP 응답

 일반적인 HTTP 응답은 다음의 형태와 같습니다. HTTP 요청과 유사합니다.

HTTP 응답 메시지

상태 라인

 상태 라인은 최상위 줄이며 역시 공백 문자(Space)로 구분된 HTTP 버전, 상태 코드, 사유로 구성됩니다.

HTTP 버전{Space}상태 코드{Space}사유

예시에서는 아래의 줄이 상태 라인이며, 의미는 HTTP 1.1 버전을 사용하며, 상태 코드와 사유는 200 OK로 요청이 성공했음을 보여줍니다.

HTTP/1.1 200 OK

• HTTP/1.1: HTTP 버전
• 200: 상태 코드
• OK: 사유

상태 코드

 HTTP 상태 코드는 3자리의 정수 코드로 첫 번째 숫자를 통해 크게 다섯 가지로 분류할 수 있습니다. 

• 1xx: 단순 정보 제공 목적입니다. 
• 2xx: 요청이 성공했음을 의미합니다.
• 3xx: 리디렉션을 의미합니다.
• 4xx: 클라이언트측 오류를 나타냅니다.
• 5xx: 서버측 오류를 나타냅니다.

 위의 각 분류에는 많은 상태 코드들이 있지만 대표적으로 아래와 같은 상태 코드들은 웹 애플리케이션을 테스트할 때 자주 볼 수 있는 상태 코드이니 반드시 숙지하셔야 합니다.

• 200 OK: 요청 성공을 의미합니다.
• 201 Created: 요청이 성공하였고, 새로운 리소스가 생성되었음을 의미합니다.. PUT,POST 요청의 결과로 사용됩니다.
• 301 Moved Permanently: 요청한 URI가 영구적으로 변경되었음을 나타냅니다. 변경된 URI는 Location 헤더에 표시하여 클라이언트에게 응답합니다.
• 302 Found: 요청한 URI가 임시적으로 변경되었음을 나타냅니다. 역시 Location 헤더에 변경된 URI를 넣어 응답합니다.
• 400 Bad Request: 클라이언트의 요청이 구문 오류로 인해 서버에서 처리할 수 없음을 의미합니다.
• 401 Unauthorized: 인증이 필요한 요청에 클라이언트가 인증없이 요청한 경우를 의미합니다. 서버는 인증 방법이 포함된 www-authenticate 헤더와 함께 응답합니다.  
• 403 Forbidden: 클라이언트가 요청한 리소스에 권한이 없어 접근이 불가함을 의미합니다.
• 404 Not Found: 클라이언트가 요청한 리소스를 찾을 수 없음을 의미합니다.
• 500 Internal Server Error: 서버측의 오류로 인해 클라이언트의 요청을 서버가 적절히 처리하지 못함을 의미합니다.
• 503 Service Unavailable: 클라이언트의 요청에 웹서버는 정상적으로 응답하지만, 구동 중인 웹 애플리케이션이 응답할 수 없음을 의미합니다.

기타 다른 상태 코드에 대한 정보는 모질라 MDN Web Docs에서 확인해보세요.

HTTP 헤더

 이제 잠깐 미루어 두었던 HTTP 헤더에 대해 살펴볼게요.

HTTP 요청과 응답은 헤더를 통해 부가적인 정보를 교환할 수 있으며, 다음과 같이 콜론(:)으로 구분되어 헤더 이름이 왼쪽에, 그 값이 오른 쪽에 위치합니다.

헤더이름: 값

HTTP 헤더는 사용되는 문맥에 따라 네 가지로 분류할 수 있습니다.

일반적인 헤더 (General Header)

 요청과 응답에서 모두 사용되는 헤더입니다.

• Cache-Control: 요청과 응답의 캐싱 메커니즘을 지정합니다.
• Connection: 요청을 전송한 후 서버와 클라이언트간의 연결을 유지할지 여부를 결정합니다. keep-alive(연결 유지), close(연결 종료) 중 하나의 값을 갖습니다.
• Date: HTTP 메시지의 생성 일시를 나타냅니다.
• Transfer-Encoding: 안전한 엔티티 전송을 위한 인코딩 형식을 지정합니다.

엔티티 헤더 (Entity Header)

 요청과 응답에서 사용되며, 메시지 바디 영역에 있는 컨텐츠와 관련된 헤더입니다.

• Content-Encoding: 컨텐츠에 사용할 인코딩 방식을 결정합니다.
• Content-Language: 사용자를 위한 언어를 지정합니다. 영어로 구현된 웹 페이지를 한국인을 대상으로 서비스한다면 헤더의 값은 ko-KR이 될 수 있습니다. 
• Content-Length: 컨텐츠의 길이를 Byte 단위로 나타냅니다.
• Content-Location: 요청된 컨텐츠를 대체하는 위치를 나타냅니다. 응답 헤더 중 하나인 Location 헤더와는 다릅니다.
• Content-Type: 컨텐츠의 종류를 나타냅니다. text/html, application/json 등의 MIME TYPE이 사용됩니다.

요청 헤더 (Request Header)

 HTTP 요청에서 사용되는 헤더입니다.

• Accept: 클라이언트가 이해할 수 있는 컨텐츠의 종류를 나타냅니다. 역시 MIME TYPE이 사용됩니다.
• Accept-Encoding: 클라이언트가 어떤 종류의 인코딩 방식을 이해할 수 있는지 나타냅니다. 서버는 이 헤더에 있는 값 중 하나를 선택하여 클라이언트에게 알려줍니다.
• Authorization: HTTP 인증 방식을 통해 사용자 식별 정보를 서버에 전달할 때 사용됩니다. 
• Cookie: 서버로부터 받은 Set-Cookie 헤더의 값을 서버에 다시 보내기 위해 사용됩니다. 쿠키 기반의 세션 메커니즘 인증 방식을 택한 웹 애플리케이션에서 사용자를 식별하기 위한 용도로 쓰입니다.
• Host: 요청이 전송될 서버의 도메인명과 포트를 나타냅니다.
• If-Match: 조건부 요청을 위한 헤더로 클라이언트가 웹 서버로부터 제공받은 리소스의 Etag 값(응답 헤더)을 갖습니다. If-Match 헤더로 전송된 Etag값과 서버에 보관된 웹 리소스의 Etag 값이 일치할 경우 요청이 성공합니다. 
• If-None-Match: If-Match 헤더처럼 Etag 값을 갖습니다. 이 헤더에 포함된 Etag 값이 서버에 저장된 웹 리소스의 Etag 값과 일치하는 경우 캐시된 리소스를 사용할 것을 지시하고, 일치하지 않는 경우에는 기존 웹 리소스를 서버로부터 다시 받습니다.
• If-Modified-Since: 캐싱 메커니즘에서 캐시된 리소스가 서버에 저장된 최신 버전(Last-Modified의 날짜 정보)과 일치하는지 확인하기 위해 사용됩니다. If-None-Match와 유사합니다.
• If-Unmodified-Since: 이 헤더에 포함된 날짜 정보가 서버에 저장된 리소스의 Last-Modified 정보보다 최신 이라면 요청이 수락됩니다.
• Referer: 현재의 요청이 어떤 페이지로부터 전송되는지 표시합니다. 즉, 현재 요청이 발생하기 바로 이전의 URL값을 포함합니다.
• User-Agent: 사용자 브라우저의 종류, 버전, 운영체제 등의 정보를 나타냅니다.

응답 헤더 (Response Header)

 HTTP 응답에서 사용되는 헤더입니다.

• Access-Control-Allow-Origin: CORS(Cross Origin Resource Sharing)를 통해 크로스 도메인간 리소스를 공유할 수 있는 호스트를 결정합니다.
• Etag: 캐싱 메커니즘에서 리소스의 버전을 식별하기 위해 사용됩니다.
• Expires: 리소스의 캐싱 만료일시를 나타냅니다. 클라이언트는 이 헤더에 표시된 일시까지 클라이언트측의 사본을 사용합니다. 
• Location: 요청에 대해 리디렉션(Redirect)할 URL을 나타냅니다.
• Pragma: no-cache 지시어를 사용해 캐시된 사본을 클라이언트에게 제공하기 전에 서버를 통해 유효성 검사를 하기 위해 사용됩니다.
• Server: 웹 서버로 사용되는 소프트웨어의 종류, 버전 등의 정보를 포함하고 있습니다.
• Set-Cookie: 쿠키를 생성해 클라이언트에게 전송할 때 사용됩니다. 이후 클라이언트는 요청할 때마다 Cookie 헤더를 통해 이 값을 자동으로 서버에 전송합니다.
• WWW-Authenticate: 요청된 리소스에 접근하기 위해 사용되어야 할 인증 방식을 정의합니다.
• X-Frame-Options: 응답된 리소스가  프레임 관련 태그 등을 통해 다른 웹페이지에 프레임 형태로 포함될 수 있을지 여부를 결정합니다. Clickjacking 공격의 방어를 위해 사용됩니다.

웹 서버

 웹 서버는 HTTP를 통해서 웹 브라우저가 요청하는 웹 리소스를 정적 혹은 동적으로 제공해주는 소프트웨어 또는 하드웨어(컴퓨터)입니다.  

여기에서는 소프트웨어 관점으로 살펴볼 것이며, 위키백과에 설명된 웹 서버의 정의를 참고해보세요. 

"웹 서버는 World Wide Web에서 클라이언트의 요청을 충족시킬 수 있는 서버 소프트웨어 또는 이 소프트웨어 실행을 위한 전용 하드웨어입니다. 웹 서버는 일반적으로 하나 이상의 웹 사이트를 포함할 수 있습니다. 웹 서버는 HTTP 및 기타 여러 프로토콜을 통해 들어오는 네트워크 요청을 처리합니다. 웹 서버의 주요 기능은 웹 페이지를 저장, 처리 및 클라이언트에 전달하는 것입니다. 클라이언트와 서버간의 통신은 HTTP(Hypertext Transfer Protocol)를 사용하여 이루어집니다. 웹 서버에 의해 제공되는 페이지는 가장 흔하게는 HTML 문서이며 텍스트 외에도 이미지, 스타일시트 및 스크립트를 포함할 수 있습니다. (이하 생략)" - 출처: 위키피디아

 보신 바와 같이 웹 서버 역시 일종의 소프트웨어이므로 리눅스나 윈도우 등의 운영체제 위에서 동작하게 됩니다. 대부분의 웹서버에서는 PHP나 ASP 등의 서버측(Server Side) 스크립팅 기능을 지원합니다. 

 웹 서버의 종류로는 아파치 HTTP 서버, NGINX, IIS(Internet Information Service), Node.js(자체적으로 웹서버 내장됨), GWS(Google Web Server) 등이 있습니다.

웹 애플리케이션

 웹 클라이언트(사용자)가 웹 브라우저를 통해 접근하고, 사용할 수 있는 응용 프로그램이며, 웹 서버 위에서 구동됩니다. 줄여서 웹 앱이라고도 부릅니다. 웹 앱은 로컬 컴퓨터에 별도의 프로그램을 설치할 필요없이 웹 브라우저만 있으면 어디서든 접근하여 사용할 수 있다는 장점이 있습니다. 물론 일부의 웹 앱은 특정 브라우저에서만 구동되기도 하지만 대부분은 웹 브라우저의 종류에 상관없이 구동됩니다.

 대표적인 웹 앱으로는 온라인 쇼핑몰이나 온라인 뱅킹, Gmail과 같은 이메일 프로그램 등이 있으며 워드, 프리젠테이션, 스프레드시트 작성을 위한 프로그램 등도 있습니다.

참고 문헌

• https://developer.mozilla.org/ko/docs/Web/HTTP
• https://ko.wikipedia.org/wiki/%EC%9B%94%EB%93%9C_%EC%99%80%EC%9D%B4%EB%93%9C_%EC%9B%B9
• https://ko.wikipedia.org/wiki/%ED%86%B5%ED%95%A9_%EC%9E%90%EC%9B%90_%EC%8B%9D%EB%B3%84%EC%9E%90
• https://ko.wikipedia.org/wiki/HTTP
• https://ko.wikipedia.org/wiki/HTTP_%EC%83%81%ED%83%9C_%EC%BD%94%EB%93%9C