HTTP(Hyper Text Transfer Protocol)

웹 상에서 브라우저와 서버가 데이터를 주고 받을 때 사용하는 프로토콜

이름에 Hypertext가 포함되어 있으나 텍스트, 미디어 등의 데이터도 전송할 수 있다.

웹 브라우저와 웹 서버의 소통을 위해 디자인되었으며, 전통적인 클라이언트-서버 아키텍처 모델에서 클라이언트가 HTTP 메시지 양식에 맞춰 요청을 보내면, 이에 서버는 HTTP 메서지 양식에 맞춰 응답을 한다.

프로토콜: 통신 규악이라는 뜻으로 데이터를 주고 받는 방식에 대한 교칙

HTTP 동작 방식

HTTP는 서버/클라이언트 모델을 따른다. 클라이언트가 서버에 요청을 보내면 서버는 요청에 맞는 응답을 클라이언트에게 보낸다.

1. connect: 클라이언트가 원하는 서버에 접속
2. request: 클라이언트가 서버에게 원하는 요청을 보냄
3. response: 서버가 요청에 대한 결과를 클라이언트에게 보내고 응답
4. close: 응답이 끝나면 서버와 클라이언트 연결 종료(Stateless)
5. HTTP 특징

• HTML 통신은 클라이언트의 요청(Request) 와 그에 대한 서버의 응답(Response)으로 이루어진다.
• 어떤 종류의 데이터라도 전송이 가능하다. HTML문서 말고도 단순 텍스트나 이미지, 오디오 등의 미디어 데이터도 전송 가능
• TCP/IP를 이용하는 응용 프로토콜로 80번 포트를 사용한다.
  • TCP에서는 바이트 스트림(Byte Stream) 서비스를 제공한다. 즉 큰 데이터를 잘게 쪼갠 뒤 전송하는 서비스다.
  • 정확히 연결되었는지 확인하기 위해서 3 hand-shaking을 활용한다. 그렇기에 TCP는 신뢰성을 담당한다.
  • IP에서는 데이터 패킷들을 목적지에 전달한다.
  • 이 때 전달 주소를 IP주소로 아는 것이 아닌, MAC 주소로 구분한다. 둘을 같이 쓰는데 계층형인 IP주소를 가고자 하는 주소의 "방향"을 알 수 있다. 여기서 ARP(Address Resolution Protocol)를 사용한다.
• 과거: 비연결성(Connectionless) 프로토콜이다. Connectionless는 한 가지 요청에 대한 응답을 받으면 그 연결을 끊어버리는 것을 의미한다. 이는 연결에 대한 리소스를 줄일 수 있는 장점이 있지만 같은 클라이언트에서 오는 요청도 계속 연결/해제 해야 한다는 단점이 있다. 그렇기에 클라이언트의 이전 상태를 서버가 알 수 없다.(stateless)
  (이를 해결하기 위해 cookie와session이 등장하였다.)
• 현재: 지속연결 프로토콜로 바뀌었다. 지속 연결을 통해 서버의 부하를 줄이고 통신속도를 높였다. 여기서 리스폰을 기다리지 않고 바로 다음을 리퀘스트를 보내는 파이프라인(pipeline)도 가능하다. 허나 이는 성능향상이 미미하기에 잘 사용되지 않는다.

Hand-shaking: 두 호스트가 서로 연결할 때에 필요한 정보들을 주고받는 일련의 과정들
    1. 요청(SYN) : 내 목소리 들려? 들려? 들려? 응답할 때 까지 지정횟수 만큼 요청
    2. 응답1(ACK) : 응 들려
    3. 응답 2(ACK): 나도 들려! 이후 요청

IP주소: 컴퓨터 주소가 아니라 LAN Card에 연결되어 있는 회선(랜선)의 주소를 말한다. 즉 고정되어 있는 것이 아니라 인터넷맘에 접속할 때마다 달라진다. (사람 이름)

MAC주소: MAC주소는 LAC Card의 주소를 말한다. 네트워크 상에서 서로를 구분하기 위해서 Device 마다 할당된 물리적인 주소이다. 인터넷이 가능한 장비(PC, 휴대폰)들이 가지고 있는 물리적인 주소라고 생각할 수 있다.(사람 주민번호)

ARP(Address Resolution Protocol, ARP): 네트워크 상에서 IP주소를 물리적 네트워크 주소로 대응(bind)시키기 위해 사용되는 프로토콜이다. 즉 IP주소를 MAC 주소와 매칭시키기 위한 프로토콜이다.

HTTP 메시지(HTTP Message)

HTTP 메시지의 요청과 응답은 유사한 구조를 가진다.

• Start line: 요청의 상태를 나타내며, 항상 첫 번째 줄에 위치한다.
• Status line: 응답의 상태를 나타내며, 항상 첫 번째 줄에 위치한다.
• HTTP headers: 요청을 지정하거나 메시지에 포함된 본문을 설명하는 헤더의 집합이다.
• empty line: 헤더와 본문을 구분하는 빈 줄이다.
• body: 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함한다.

요청(Requests)

HTTP Requests는 클라이언트가 서버에 보내는 메시지다.

Start line

• 수행할 작업(GET, PUT, POST 등)이나 방식(HEAD, OPTIONS)을 설명하는 HTTP 메서드를 나타낸다.
• 요청 대상(URL 또는 URI) 또는 프로토콜, 포트, 도메인의 절대 경로 등은 요청 컨텍스트에 작성되며 HTTP 메서드마다 다르게 작성된다.
• HTTP 버전에 따라 HTTP 메서드의 구조가 달라진다. 따라서 start line에 HTTP 버전이 함께 입력된다.

URI(Unifrom Resource Identifier): 자원의 위치 뿐만 아니라 자원에 대한 고유 식별자로서 URL 의미를  포함한다.
    e.g. https://naver.com/mail?page=12
URL(Uniform Resource Locator): Resource의 정확한 위치 정보(파일의 위치)를 나타낸다.
    e.g. https://naver.com/mail

Headers

HTTP Requests의 Headers는 기본 구조를 따른다.
헤더의 이름, 콜론, 값 형태로 입력되며 값은 헤더에 따라 다르다.

• 일반 헤더(General headers): 메시지 전체에 적용되는 헤더로 body를 통해 전송되는 데이터와는 관련이 없는 헤더이다.
• 요청 헤더(Request headers): fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더를 의미한다.
• 표현 헤더(Representation headers): body에 담긴 리소스의 정보(컨텐츠 길이, mime 타입 등)를 포함하는 헤더이다.

Body

Body는 요청의 본문으로 HTTP 메시지 구조의 마지막에 위치한다. 모든 요청에 body가 필요한 것은 아니다.

GET, HEAD, DELETE, OPTIONS처럼 서버에 리소스를 요청하는 경우에는 본문이 필요하지 않다.
단, POST나 PUT과 같은 일부 요청에 대해서는 데이터를 업데이트하기 위해 body를 사용한다.

응답(Responses)

HTTP Responses는 클라이언트의 요청을 서버가 응답하는 것이다.

Status line

현재 프로토콜의 버전, 요청의 결과를 나타내는 상태 코드, 그리고 상태 코드에 대한 설명을 나타내는 상태 텍스트가 담겨있다.

Headers

• 일반 헤더(General headers): 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더이다.
• 응답 헤더(Response headers): 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더이다. Vary, Accept-Ranges와 같은 상태 줄에 넣기에는 공간이 부족한 추가 정보를 제공한다.
• 표현 헤더(Representation headers): body에 담긴 리소스의 정보(컨텐츠 길이, MIME 타입 등)를 포함하는 헤더이다.

body

응답의 바디에는 HTTP 메시지 구조의 마지막에 위치한다. 모든 응답에 body가 필요하지는 않다. 201, 204와 같은 상태 코드를 가지는 응답에는 본문을 필요로 하지 않는다.

HTTP Method

HTTP를 이용하여 클라이언트에서 서버로 요청을 보낼 때 어떠한 목적으로 요청을 하는 것인지 정의를 내릴 수 있다.
예를 들어 '단순 조회'를 목적으로 하는지, '데이터 수정'을 목적으로 하는지 등을 미리 정의내려서 요청을 보낼 수 있는데 이 때 HTTP Method라는 것을 사용한다.

이름	역할
GET	서버에게 데이터를 달라는 요청을 할 때 사용
HEAD	GET과 같지만 서버가 응답할 때 Body없이 Header만 리턴
POST	서버에게 데이터를 전송하는 요청할 때 사용
PUT	서버에서 요청 URI의 데이터를 수정하거나 새로 추가하도록 요청할 때 사용
PATCH	서버의 데이터를 일부 수정할 때 사용
DELETE	서버에서 요청 URI의 데이터를 삭제하도록 요청할 때 사용
TRACE	클라이언트로부터 수신한 요청을 응답에 포함시켜서 전달(디버깅용)
OPTIONS	서버에게 특정 데이터가 어떤 Method를 지원하는지 알아볼 때 사용

HTTP 상태 코드

HTTP Status 코드라고 불리며, 서버가 응답을 전송할 때 같이 전송하는 코드이다.
앞 자리는 1~5의 숫자 중 하나이며 이 중 4와 5는 비정상적인 상황, 즉 오류가 있음을 의미한다.

MDN의 상태코드
MDN의 상태코드-고양이

1. 1xx - 정보 응답
   • 100 continue: 현재 요청이 진행중이며 문제 없다는 것을 의미한다.
2. 2xx - 성공 응답
   • 200 OK: 요청이 성공적으로 완료되었음을 의미한다.
   • 201 Created: 요청이 성공적으로 완료되었고 새로운 리소스가 생성되었음을 의미한다. 보통 POST아니면 PUT요청이 뒤에 따라온다.
3. 3xx - 리다이렉션 메시지
   • 300 Multiple Choice: 요청에 대해 하나 이상의 응답이 가능함을 의미한다.
   • 301 Moved Permanently: 요청한 리소스의 URI가 변경되었음을 의미한다.
4. 4xx - 클라이언트 에러 응답
   • 400 Bad Request: 잘못된 문법으로 인해 서버가 요청을 이해하지 못했음을 의미한다.
   • 401 Unauthorized: 요청을 보낸 클라이언트가 인증되지 않았음을 의미한다.
   • 403 Forbidden: 요청을 보낸 클라이언트가 리소스에 접근할 권리가 없음을 의미한다.
   • 404 Not Found: 서버가 요청받은 리소스를 찾을 수 없음을 의미한다.
   • 408 Request Timeout: 요청 중 시간이 초과되었음을 의미한다.
   • 418 I'm a Teapot: 서버가 찻주전자이기 때문에 커피 내리기를 거절했다는 의미이다.
5. 5xx - 서버 에러 응답
   • 500 Internal Server Error: 서버에 문제가 있지만 서버가 해당 문제를 처리할 줄 모름을 의미한다.
   • 502 Bad Gateway: 서버가 게이트웨이로부터 잘못된 응답을 받았음을 의미한다.
   • 503 Service Temporarily Unavailable: 일시적으로 서버를 이용할 수 없음을 의미한다. 보통 유지보수를 위해 서버를 잠시 중단시켰거나 과부하로 인한 다운이 원인이다.
   • 504 Gateway Timeout: 서버가 게이트웨이 역할을 하고 있으며 다른 서버로부터 적시에 응답을 받지 못했음을 의미한다.

HTTPS란?

HyperText Transfer Protocol over Secure Socket Layer의 약자인 HTTPS는 HTTP에 데이터 암호화가 추가된 프로토콜이다. HTTPS는 HTTP와 다르게 443번 포트를 사용하며, 네트워크 상에서 중간에 제 3자가 정보를 볼 수 없도록 암호화를 지원하고 있다.

대칭키 암호화와 비대칭키 암호화

HTTPS에서는 대칭키 암호화 방식과 비대칭키 암호화 방식을 모두 사용하고 있다.

• 대칭키 암호화
  • 클라이언트와 서버가 동일한 키를 사용해 암호화/복호화를 진행함
  • 키가 노출되면 매우 위험하지만 연산 속도가 빠름
• 비대칭키 암호화
  • 1개의 쌍으로 구성된 공개키와 개인키를 암호화/복호화 하는데 사용함
  • 키가 노출되어도 비교적 안전하지만 연산 속도가 느림

비대칭키 암호화

비대칭키 암호화는 공개키/개인키 암호화 방식을 이용해 데이터를 암호화하고 있다. 공개키와 개인키는 서로를 위한 1쌍의 키이다.

• 공개키: 모두에게 공개가능한 키
• 개인키: 나만 가지고 알고 있어야 하는 키
  암호화를 공개키로 하느냐 개인키로 하느냐에 따라 상황이 달라진다.
• 공개키 암호화: 공개키로 암호화를 하면 개인키로만 복화화할 수 있다. -> 개인키는 나만 가지고 있으므로, 나만 볼 수 있다.
• 개인키 암호화: 개인키로 암호화하면 공개키로만 복호화할 수 있다. -> 공개키는 모두에게 공개되어 있으므로, 내가 인증한 정보임을 알려 신뢰성을 보장할 수 있다.
  

  

HTTPS의 동작 과정

HTTPS는 대칭키 암호화와 비대칭키 암호화를 모두 사용하여 빠른 연산 속도와 안전성을 모두 얻고 있다.
HTTPS 연결 과정(Hand-Shaking)에서는 서버와 클라이언트 간에 세션키를 교환한다. 여기서 세션키는 주고 받는 데이터를 암호화하기 위해 사용되는 대칭키이며, 데이터 간의 교환에는 빠른 연산 속도가 필요하므로 세션키는 대칭키로 만들어진다.

이 때 대칭키, 즉 세션키를 서버, 클라이언트 사이에 공유하는 과정에서 비대칭키가 사용된다.
즉, 처음 연결을 성립하여 안전하게 세션키를 공유하는 과정에서 비대칭키가 사용되는 것이고, 이후에 데이터를 교환하는 과정에서 빠른 연산 속도를 위해 대칭키가 사용되는 것이다.

실제 HTTPS 연결 과정이 성립되는 흐름은 다음과 같다.

1. 클라이언트가 서버로 최초 연결 시도를 함
2. 서버는 공개키(엄밀하게는 인증서)를 브라우저에게 넘겨줌
3. 브라우저는 인증서의 유효성을 검사하고 세션키를 발급함
4. 브라우저는 세션키를 보관하며 추가로 서버의 공개키로 세션키를 암호화하여 전송함
5. 서버는 개인키로 암호화된 세션키를 복호화하여 세션키를 얻음
6. 클라이언트와 서버는 동일한 세션키를 공유하므로 데이터를 전달할 때 세션키로 암호화/복호화를 진행함

HTTPS의 발급 과정

서버는 클라이언트와 세션키를 공유하기 위한 공개키를 생성해야 하는데, 일반적으로는 인증된 기관(Certificate Authority)에 공개키를 전송하여 인증서를 발급받는다.

1. A기업은 HTTP 기반의 애플리케이션에 HTTPS를 적용하기 위해 공개키/개인키를 발급함
2. CA 기업에게 돈을 지불하고, 공개키를 저장하는 인증서의 발급을 요청함
3. CA 기업은 CA기업의 이름, 서버의 공개키, 서버의 정보 등을 기반으로 인증서를 생성하고, CA 기업의 개인키로 암호화하여 A기업에게 이를 제공함
4. A기업은 클라이언트에게 암호화된 인증서를 제공함.
5. 브라우저는 CA기업의 공개키를 미리 다운받아 갖고 있어, 암호화된 인증서를 복호화함
6. 암호화된 인증서를 복호화하여 A기업의 공개키로 세션키를 공유함

인증서는 CA의 개인키로 암호화되었기에 신뢰성을 확보할 수 있다.
클라이언트는 A 기업의 공개키로 데이터를 암호화하였기 때문에 A기업만 복호화하여 원본의 데이터를 얻을 수 있다.
여기서 인증서에는 A 기업의 공개키가 포함되어 있으므로, A 기업의 공개키라고 봐도 무방하다.
또한 브라우저에는 인증된 CA 기관의 정보들이 사전에 등록되어 있어 인증된 CA기관의 인증서가 아닐 경우 다음과 같은 형태로 브라우저에서 보여지게 된다.

HTTP/HTTPS

HTTP는 암호화가 추가되지 않았기에 보안이 취약하고 HTTPS는 안전하게 데이터를 주고받을 수 있다. 허나 HTTPS의 경우 암호화/복호화 과정이 필요하기에 HTTPS보다 속도가 느리다. 또한 HTTPS는 인증서를 발급하고 유지하기 위한 추가 비용이 발생한다.

개인정보와 같은 민감한 데이터를 주고 받아야 한다면 HTTPS를, 노출이 되어도 괜찮은 단순한 정보 조회 등 만을 처리하고 있다면 HTTP를 이용하면 된다.

ref

https://jin-network.tistory.com/46
https://mangkyu.tistory.com/98
https://seing.tistory.com/183?category=552898
https://tibetsandfox.tistory.com/18
https://ittrue.tistory.com/192
https://jaehoney.tistory.com/290

웹 페이지

웹페이지는 브라우저에 표시 될 수 있는 간단한 문서이다. 이러한 문서는 HTML언어로 작성된다. 웹페이지에는 다음과 같은 유형의 리소스가 포함된다.

• 스타일(css)
• 스크립트(js,ts)
• 미디어: 이미지, 사운드, 비디오

웹 사이트

웹 사이트는 고유한 도메인 이름을 공유하는 웹페이지의 모음이다. 특정 웹사이트의 각 웹페이지는 사용자가 그 사이트의 다른 페이지로 이동할 수 있는 (클릭가능한)링크를 제공한다.

웹 서버

웹 서버는 하나 이상의 웹사이트를 호스팅하는 컴퓨터이다. "호스팅"은 모든 웹 페이지와 해당 지원을 해당 컴퓨터에서 사용할 수 있음을 의미한다. 웹 서버는 사용자 요청에 따라 호스팅하는 웹 사이트의 모든 웹 페이지를 모든 사용자의 브라우저로 보낸다.
만일 "웹 사이트가 응답하지 않아요!" 라고 말하는 경우는 "웹 서버"가 응답하지 않아 "웹 사이트"를 이용할 수 없다는 의미이다.

검색 엔진

검색 엔진은 사람들이 다른 웹사이트를 찾는데 도움을 주는 웹사이트이다. 참고로 브라우저는 웹 페이지를 표시하는 소프트웨어다.

네트워크

두 개의 컴퓨터가 통신을 한다면? 유선 연결(이더넷 케이블)을 하거나 무선(WIFI, Bluetooth)으로 연결해야 한다.
(아래의 경우 전부 유선으로 가정)
만일 두 대의 컴퓨터라면 1개의 케이블, 세 대의 컴퓨터라면 3개, ... 만일 10대라면 45개의 케이블이 필요하다.
이러는 큰 단점으로 다가오는데 이를 극복하고자 라우터라는 소형 컴퓨터에 모든 컴퓨터를 연결하였다.

라우터(Router): 
    디바이스가 인터넷 또는 인트라넷을 통해 연결하여 데이터를 공유할 수 있게 해준다. 
    한 개 이상의 근거리 통신망(LAN) 간에 데이터를 전달하는 게이트웨이이다. 
    라우터는 인터넷 프로토콜(IP)을 사용하여 데이터가 포함된 IP패킷을 전송하며,
    분리된 각각의 근거리 통신망(LAN)에 위치한 원본 및 대상 디바이스의 IP주소를 사용한다. 
    라우터는 송신 디바이스와 수신 디바이스가 연결되는 이러한 LAN 사이에 위치한다.

인트라넷(Intranet):
    특정 조직에서만 사용 가능한 '사내망'으로 조직 내부에서만 접속이 가능하다.

게이트웨이(Gateway):
    컴퓨터 네트워크에서 서로 다른 통신망, 프로토콜을 사용하는 네트워크 간의 통신을 
    가능하게 하는 컴퓨터나 소프트웨어를 두루 일컫는 용어,
    즉 다른 네트워크로 들어가는 관문 역할을 하는 네트워크 포인트이다. 
    종류가 다른 네트워크 간의 통로의 역할을 하는 장치. 

트래픽(Traffic):
    서버의 데이터 전송량을 의미한다. 외부에서 해당 서버에 접속을 많이 시도할 수록 트래픽이 증가한다.
    트래픽이 서버가 버틸 수 있는 한계를 넘어서 지속적으로 들어올 경우, 서버는 버티지 못하고 다운되어 버린다.
    이 점을 이용하여 상대방 서버를 마비시키는 것을 서비스 거부 공격(DoS)라고 한다.

패킷(Packet):
    (네트워크)패킷은 네트워크를 통해 전송되는 형식화된 데이터 덩어리다.
    네트워크 패킷의 주요 컴포넌트는 사용자 데이터와 제어 정보이다.
    사용자 데이터는 'payload'로 알려져 있고, 제어정보는 payload를 전달하기 위한 정보이다.

라우터는 조율자 역할을 한다. 예를 들어 A컴퓨터가 B컴퓨터로 메시지를 보내고자 한다. 그렇다면 A컴퓨터는 라우터에게 메시지를 보내고 라우터는 정확하게 B컴퓨터에 메시지를 전달해준다. 라우터 또한 컴퓨터이기에 라우터와 라우터를 연결할 수 있다. 그렇게 된다면, 컴퓨터를 무한히 확장할 수 있다.
허나 이또한 제약이 있다. 만일 먼 거리에 있는 사람에게 메시지를 보내고자한다면, 매우 많은 라우터, 케이블이 필요할 것이다. 그렇기에 이를 극복하고자 이미 설치되어 있는 전화기의 케이블을 활용한다. 이미 전화기의 기반 인프라는 모든 곳에 연결되어있기에 활용하기 좋은 요소이다. **모뎀**이라는 장비를 통해, 네트워크의 정보를 전화 시설에서 처리 할 수 있는 정보로 바꾸어 사용할 수 있게 한다. 이렇게 네트워크들은 전화 시설에 연결된다.

모뎀(MOdulator and DEModulator, MODEM):
    컴퓨터, 스마트폰, 태블릿 및 기타 장치를 인터넷에 연결할 수 있게 해주는 장치다.  

이렇게 연결된 네트워크를 우리가 사용하고자한다면, 네트워크를 인터넷 서비스 제공업체(Internet Service Provider, ISP) 에 연결해야한다. ISP는 서로 연결되어 있는 몇몇 특수한 라우터를 관리하고 심지어 다른 ISP의 라우터에도 액세스 할 수 있는 회사이다. 이를 통해 사용자의 네트워크의 메시지는 ISP의 네트워크를 통해 목적지 네트워크로 전달된다.

ISP(Internet Service Provider): 
    인터넷에 접속하는 수단을 제공하는 주체를 가리키는 말. 
    이들은 곳곳에 인터넷 케이블들을 깔아두고, 우리는 돈을 주고 이 케이블을 사용하는 것이다.
    흔히 sk, lg, kt가 있다.  
    인터넷은 이러한 전체 네트워크 인프라로 구성된다.  

컴퓨터 찾기

특정 컴퓨터에 메시지를 보내고자 한다면 특정 메시지를 지정할 수 있어야 한다. 네트워크에 연결된 모든 컴퓨터에는 **IP주소**라는 고유한 주소가 있다. 주소는 점으로 구분 된 네 개의 숫자로 구성된 주소이다. (e.g. 192.168.0.2)
컴퓨터는 이러한 주소로 다른 컴퓨터를 찾아가는데 문제가 없지만, 사용자 입장에서 IP주소를 기억하기는 어렵다. 그렇기에 '도메인 이름' 을 부여하여 사람이 읽을 수 있는 IP주소의 이름을 지정할 수 있다. (e.g. 173.194.121.32는 google.com)

인터넷과 웹 웹 브라우저에서 도메인 이름을 사용하여 웹 사이트에 접속한다. 허나 이는 '인터넷 = 웹'을 의미하는 것이 아니다.
정확하게는 몇억 대의 컴퓨터를 연결하는 인프라인 인터넷에서, '웹 서버' 서비스를 제공하는 것이다. 이밖에 'email', 'IRC(internet Relay Chat)'의 서비스가 있다.

클라이언트와 서버 웹에 연결된 컴퓨터는 클라이언트와 서버라고 한다.

• 클라이언트는 일반적인 웹 사용자의 인터넷이 연결된 장치들과 이런 장치들에서 이용가능한 웹에
  접근하는 소프트웨어(e.g. chrome)이다.
• 서버는 웹페이지, 사이트, 또는 앱을 저장하는 컴퓨터이다.
  클라이언트의 장비가 웹페이지에 접근하길 원할 때, 서버로부터 클라이언트의 장치로 사용자의
  웹 브라우저에서 보여지기 위한 웹페이지의 사본이 다운로드 된다.

웹 주소를 입력할 때

1. 브라우저는 DNS 서버로 가서 웹사이트가 있는 서버의 진짜 주소를 찾는다.
2. 브라우저는 서버에게 웹사이트의 사본을 클라이언트에게 보내달라는 HTTP 요청 메세지를 서버로 전송한다. 이 메세지, 그리고 클라이언트와 서버 사이에 전송된 모든 데이터는 TCP/IP 연결을 통해서 전송된다.
3. 이 메세지를 받은 서버는 클라이언트의 요청을 승인하고, "200"의 HTTP 상태코드를 클라이언트에게 전송한다. 그 다음 서버는 웹사이트의 파일들을 데이터 패킷이라 불리는 작은 일련의 덩어리들로 브라우저에 존상하기 시작한다.
4. 브라우저는 이 작은 덩어리들을 합쳐 웹 사이트를 보여준다.

TCP/IP:
    Transmission Control Protocol(전송 제어 규약)과 Internet Protocol(인터넷 규약)은 
    컴퓨터와 컴퓨터간의 지역네트워크(LAN)과 광역네트워크(WAN)에서 원활한 통신을 가능하도록 하기위한 통신 규악이다.
    TCP/IP는 하드웨어, 운영체제, 접속매체에 관계없이 동작할 수 있다는 개방성 때문에 선택되었다.
    이름 그대로 2개의 프로토콜이 이루어져 있다. IP기반에 TCP가 사용된다.
    즉 IP프로토콜위에 TCP 프로토콜이 놓이는 것이다. 주방과 손님을 이어주는 홀서버와 비슷하다.

IP:
    네트워크 상에서 컴퓨터는 고유한 주소가 있다. 컴퓨터의 주소는 인터넷에 접속할 때 컴퓨터 각각에 부여받는다.
    이 주소는 총 4바이트로 이루어져 있다.


TCP:
    클라이언트와 서버간에 데이터를 신뢰성 있게 전달하기 위해 만들어진 프로토콜이다. 
    TCP는 근거리 통신망(LAN), 원거리 통신망(WAN), 인트라넷, 인터넷 등 컴퓨터에서 실행되는
    프로그램 간에 일련의 데이터를 안정적으로 순서대로 에러없이 데이터를 교환할 수 있게 한다.

DNS(Domain Name system Server):
    웹사이트를 위한 주소록과 같다. 사용자가 웹 도메인명을 입력할 때,
    브라우저는 DNS에서 도메인명을 검색하고 웹 IP주소를 알아낸다. 그 다음 IP 주소를 브라우저에 전달한다.

HTTP(HyperText Transfer Protocol):
    클라이언트와 서버가 서로 통신할 수 있게 하기 위한 언어를 정의하는 어플리케이션 규약이다.
    손님과 주방과 홀서버의 언어를 통일시키는 것과 비슷하다.

컴포넌트 파일:
    코드 파일: HTML, CSS, JAVASCRIPT따위의 언어
    자원: 이미지, 음악, 비디오, 단어, PDF 따위의 자원들

HTTP 상태코드:
    특정 HTTP 요청이 성공적으로 완료되었는지 알려준다. 응답은 5개의 그룹으로 나뉘는데,
    정보를 제공하는 응답, 리다이렉트, 클라이언트 에러, 그리고 서버 에러가 있다.

패킷과 프로토콜

자원을 전송할 때는 패킷(packet) 단위로 나눈 데이터 조각이 오간다. 이러한 패킷들은 전자 신호로 변환되어 이더넷 케이블 이라는 전선을 먼저 통과해야 한다. 전자 신호는 0과 1로 이루어져 있고, 이 신호를 아무런 양식없이 전송한다면 이것이 텍스트인지, 이미지인지 구분할 수 없다. 그렇기에 특정 양식, 즉 통신 규약을 정해놓았는데, 이를 프로토콜이라고 한다. 대표적으로 TCP/IP 4 Layer이라고 한다. 이는 프로토콜을 각 역할로 구분하여 계층을 나눠놓은 것이다.

• L4 - 응용계층 (HTTP, FTP, SMTP 등): 웹(HTTP), 이메일(SMTP), 파일전송(FTP) 같은 응용프로그램을 위한 프로토콜
• L3 - 전송계층(TCP): 응용프로그램을 구분하는 포트 번호를 통해 컴퓨터에서 돌아가는 프로그램들 중 특정 응용 프로그램 하나를 찾아감
• L2 - 인터넷 계층(IP) : IP 주소를 통해 수많은 컴퓨터들 중 특정 컴퓨터 하나를 찾아감
• L1 - 네트워크 연결 계층: 전선과 장비들을 통해 물리적으로 데이터를 전송하기 위해 적절한 디지털/아날로그 신호 등등으로 변환함

응용 프로그램에서 데이터를 전송하면 각 프로토콜에 따라 패킷이 만들어지고, 아래 계층으로 내려가며 각 계층에 따라 다른 정보가 덧붙여져 간다. 이후 마지막 네트워크 계층에서 전선과 장치를 통해 인터넷으로 전송되고, 아래 계층부터 위 계층까지 차례대로 거쳐 프로토콜에 의해 원본 데이터에 해석된다.
이러한 구분을 통해 서로 간에 간섭이 최소화되어 편하고, 응용 계층에서는 응용 프로그램끼리의 해석만 신경 쓰면 되고 그 밑으로 각 계층마다 어떤 포트로, 어떤 IP로, 어떻게 디지털/아날로그 신호로 바꾸면되는지 따위를 신경만 쓰면된다.