320x100
320x100
시작하기 전에..
책의 마지막 챕터인 네트워크 활용을 제외하고는 TCP/IP 5계층 모델에서는 제일 위의 계층인 응용 계층(Application Layer) 편이다!
면접에서는 DNS, HTTP Status Code 등이 나오는 편이다
독서 & 스터디
이번주는 잠깐 카페에서 공부하고, 집에서 Ebook으로 주로 공부했다
저번주 우수 혼공족으로 선정돼서 베스킨라빈스 쿠폰으로 베라 아이스크림도 먹고, 50% 완주한 기념으로 받은 메가커피 햄앤치즈샌드도 있었는데 이건 전국 매장에서 햄앤치즈가 지금 생산이 안된다고 해서 다른 메뉴(할메가커피)로 바꿔먹었다!
감사합니다. 혼공족장님. 한빛미디어님
도메인 네임과 네임 서버
도메인 네임(Domain Name)
- IP주소만으로는 호스트를 특정하기 어려움(번거로움)
- 호스트의 IP주소는 언제든지 바뀔 수 있음
- 상대 호스트를 특정하기 위해 일반적으로 IP 주소보다 도메인 네임(domain name)을 많이 사용
- IP 주소와 대응되는 문자열 형태의 호스트 특정 정보
- IP 주소에 비해 기억하기 쉬울뿐더러, IP 주소가 바뀌더라도 바뀐 IP 주소에 도메인 네임을 다시 대응하면 됨
- 호스트의 도메인 네임과 IP 주소를 모아 관리하는 '공용' 전화번호부와 같은 역할
- ex) www.example.com, git.kernel.org
DNS(도메인 네임 서버, Domain Name Server)
- 도메인 네임을 관리하는 네임 서버
- DNS 서버라고도 부름
- 도메인 네임을 네임 서버에 질의하면 해당 도메인 네임에 대한 IP 주소를 얻을 수 있음
- 반대로 IP 주소를 통해 도메인 네임을 알아내는 것도 가능
'개인' 전화번호부와 같은 hosts 파일
- '공용' 전화번호부와 같은 네임 서버와 유사하게 개인의 컴퓨터에 저장된 주소록
- hosts 파일은 도메인 네임과 IP 주소의 대응 관계를 담은 파일
- 호스트(컴퓨터)마다 개별적으로 보유하는 파일이므로 마치 개인 전화번호부와 같음
- 전 세계에 있는 모든 호스트의 <IP-도메인 네임>을 모두 다 알 수는 없기 때문에 공용전화번호부인 네임서버가 필요
- host 파일의 위치는 운영체제별 상이
- 맥OS/리눅스: /etc/hosts
- 윈도우: %SystemRoot%\System32\drivers\etc\hosts
도메인 네임의 계층적인 형태
www.example.com(.)
- 루트 도메인(일반적으로 생략): .
- 최상위 도메인: com
- 2단계 도메인: example
- 3단계 도메인: www
- 전체 주소 도메인 네임(FQDN): www.example.com.
도메인 네임의 계층적 분류
- 루트 도메인(Root Domain)
- 최상위 도메인(TLD: Top-Level Domain)
- n-th 단계 도메인
전체 주소 도메인 네임(FQDN: Fully-Qualified Domain Name)
- www.example.com. < 처럼 도메인 네임을 모두 포함하는 도메인 네임
- FQDN의 첫 번째 부분(www)를 호스트 네임(host name)이라 부르기도 함
- 때때로 '호스트 네임'이라는 용어는 FQDN 자체를 가리키기도 하고, 네트워크 장치 자체의 이름을 가리키는 데 사용되기도 함
DNS(도메인 네임 시스템)
- 계층적인 도메인 네임을 효율적으로 관리하기 위해 네임 서버 또한 계층적인 형태를 이룸
- 네임 서버는 여러 개 존재하며 전 세계 여러 군데에 위치해 있음
- 계층적이고, 분산된 도메인 네임에 대한 관리 체계를 도메인 네임 시스템, DNS라고 부름
- DNS는 호스트가 이러한 도메인 네임 시스템을 이용할 수 있도록 하는 애플리케이션 계층 프로토콜을 의미하기도 함
서브 도메인(sub domain)
- 다른 도메인이 포함된 도메인을 의미
- 예를 들어 아래는 모두 google.com의 서브 도메인(모두 google.com을 포함하고 있기 때문)
- mail.google.com
- www.google.com
- scholar.google.com
- drive.google.com
- 마찬가지로 google.com은 com을 포함하고 있기에 com의 서브도메인이라 할 수 있음
계층적 네임 서버
IP Address Resolving
- IP 주소를 모르는 상태에서 도메인 네임에 대응되는 IP를 알아내는 과정
- 도메인 네임을 풀이(resolve)한다라고 표현
- 영어로는 리졸빙(Resolving)
네임 서버의 유형
- 로컬 네임 서버
- 루트 네임 서버(루트 DNS 서버)
- TLD(최상위 도메인) 네임 서버
- 책임(Authoritative) 네임 서버
로컬 네임 서버 - local name server
- 클라이언트와 맞닿아 있는 네임 서버
- 클라이언트가 도메인 네임을 통해 IP 주소를 알아내고자 할 때 가장 먼저 찾게 되는 네임 서버
- 클라이언트가 로컬 네임 서버를 찾을 수 있으려면 로컬 네임 서버의 주소를 알고 있어야 함
- 로컬 네임 서버의 주소는 일반적으로 ISP에서 할당해 주는 경우가 많음
- 다만 ISP에서 할당해 주는 로컬 네임 서버 주소가 아닌, 공개 DNS 서버(public DNS server)를 이용할 수도 있음
- 공개 DNS 서버의 대표적인 예
- 구글: 8.8.8.8, 8.8.4.4
- 클라우드플레어: 1.1.1.1
루트 네임 서버 - root name server
- 루트 도메인을 관장하는 네임 서버
- 로컬 네임 서버가 대응되는 IP 주소를 모를때 질의하는 서버
- 질의에 대해 TLD 네임 서버의 IP 주소 반환
TLD 네임 서버 - Top-Level Domain name server
- TLD를 관리하는 네임 서버
- 로컬 네임 서버가 루트 네임 서버로부터 받은 TLD 서버로 질의
- 하위 도메인 네임을 관리하는 네임 서버의 주소 반환
책임 서버 - Authoritative name server
- 특정 도메인 영역(zone)을 관리하는 네임 서버
- 자신이 관리하는 도메인 영역의 질의에 대해서는 다른 네임 서버에서 떠넘기지 않고 곧바로 답할 수 있는 네임 서버
- 다시 말해, 책임 서버는 로컬 네임 서버가 마지막으로 질의하는 네임 서버
- 일반적으로 로컬 네임 서버는 책임 네임 서버로부터 원하는 IP 주소를 얻어냄
- 위에서 첨부했던 이미지에서 살펴보면.. authoritative answer라고 나온다!!
도메인 네임 리졸빙 방법 2가지(How to Get IP Address byDomain Name)
- 재귀적 질의(recursive query)
- 클라이언트가 로컬 네임 서버에게 도메인 네임 질의
- 로컬 네임 서버가 루트 네임 서버에게 질의
- 루트 네임 서버가 TLD 네임 서버에 질의
- TLD 네임 서버가 다음 단계에 질의
- 위의 과정을 반복하여 최종 응답 결과를 역순으로 전달
- 반복적 질의(iterative query)
- 클라이언트가 로컬 네임 서버에게 도메인 네임 질의
- 로컬 네임 서버는 루트 도메인 서버에게 질의해서 다음으로 질의할 네임 서버의 주소를 클라이언트에게 응답
- 다음으로 TLD 네임 서버에게 질의해서 다음으로 질의할 네임 서버의 주소를 응답
- 위의 과정을 반복하다가 최종 응답 결과를 클라이언트에 알려주는 방식
1, 2과정을 요약해보면
1번 - [루트네임서버 -> TLD -> 책임] Top-down & Bottom-UP 으로 Request/Response
2번 - [로컬네임서버 -> Root], [로컬네임서버 -> TLD], [로컬네임서버 -> 책임네임서버]로 Request/Response
DNS 캐시(DNS Cache)
- 위의 과정을 계속 반복한다면 루트 도메인에 과부하가 계속 생기고, 속도도 느릴것!
- DNS 캐시: 실제로는 네임 서버들이 기존에 응답받은 결과를 임시로 저장하고, 추후 같은 질의에 이를 활용
- DNS 캐시를 저장하는 용도로만 사용되는 서버도 존재
- DNS 캐시를 활용해서 더 짧은 시간 안에 원하는 IP 주소 획득 가능
- DNS 캐시는 영원히 저장되지 않고 TTL(Time To Live) 값과 함께 저장되며, 이 TTL은 도메인 네임의 결과를 임시로 저장하는 시간
(패킷의 TTL과는 다른 의미)
자원을 식별하는 URI
자원(Resource)
- 네트워크상의 메시지를 통해 주고받는 대상
- HTML 파일, 이미지, 동영상, 텍스트 파일, XML, JSON
- 두 호스트가 네트워크를 통해 서로 정보를 주고받을 때, 송수신하는 대상
- RFC 9110 - The Target of an HTTP request is called a "resource".
URI(Uniform Resource Identifier)
- 자원을 식별할 수 있는 정보
- 이름 그대로 자원(Resource)을 식별(Identifier)하는 통일된 방식(Uniform)
URL(Uniform Resource Locator)
[ 일반적인 URL 형식 ]
foo://www.example.com:8042/over/there?name=ferret#nose
- scheme: foo://
- authority: www.example.com:8042
- path: /over/there
- query: ?name=ferret
- fragment: #nose- 위치를 이용해 자원을 식별
- 오늘날 인터넷 환경에서 자원 식별에 더 많이 사용되는 방법
- URL 표기 설명
- scheme: 자원에 접근하는 방법, 사용할 프로토콜 명시, ex) http://, https://
- authority: 호스트를 특정할 수 있는 정보. IP 주소 또는 도메인 네임 명시, ex) www.google.com
- path: 자원이 위치한 경로. 자원의 위치는 /를 기준으로 계층적으로 표현, ex) /home/images/a.png
- query: 자원을 요청할 때 사용하는 변수(쿼리). 쿼리 문자열(query string) 또는 쿼리 파라미터(query parameter). ?로 시작해서 &를 이용해 and조건을 더할 수 있음. ex) ?name=boki&age=30
- fragment: 자원의 한 조각을 가리키기 위한 정보. 보통 HTML에서 id를 찾아서 갈때 #을 통해 찾아갈 수 있음. ex) https://docs.spring.io/spring-ai/reference/getting-started.html#spring-cli
URN(Uniform Resource Name)
urn:isbn:0451450523- 이름을 이용해 자원 식별
- URL만큼 아직 널리 채택된 방식은 아님
- 자원의 위치가 언제든 변할 수 있는 URL의 고질적인 문제를 해결 가능
- 자원에 고유한 이름을 붙이는 이름 기반 식별자이기에 자원의 위치와 무관하게 자원 식별 가능
DNS 레코드 타입
- DNS 자원 레코드(DNS resource record): 네임 서버가 저장하는 정보
- 단순히 DNS 레코드라고 부르기도 함
- 도메인 네임을 구입하고, 웹 사이트에 도메인 네임을 적용시킬 때 사용
- 도메인 네임 example.com을 구입하고 1.2.3.4에 대응된다는 사실을 네임 서버에 알려야 함
- -> 도메인 레코드를 추가해서 해결 가능
| 레코드 유형 | 설명 |
| A | 특정 호스트에 대한 도메인 네임과 IPv4 주소와의 대응 관계 |
| AAAA | 특정 호스트에 대한 도메인 네임과 IPv6 주소와의 대응 관계 |
| CNAME | 호스트 네임에 대한 별칭 지정 |
| NS | 특정 호스트의 IP 주소를 찾을 수 있는 네임 서버 |
| MX | 해당 도메인과 연동되어 있는 메일 서버 |
예시
| 타입 | 이름 | 값 | TTL |
| A | example.com. | 1.2.3.4 | 300 |
| CNAME | www.example.com. | example.com | 300 |
- A타입에 CNAME 레코드를 추가했기 때문에
- example.com -> 1.2.3.4
- www.example.com -> example.com -> 1.2.3.4
- 로 접속이 가능함
HTTP(Hypertext Transfer Protocol)
요청-응답 기반 프로토콜
- 요청헤더/바디 -> 응답헤더/응답바디 구성
미디어 독립적 프로토콜
- 미디어 타입(Media Type): HTTP에서 메시지로 주고받는 자원의 종류
- MIME 타입(Multipurpose Internet Mail Extensions Type)이라고도 부름
- HTTP를 통해 HTML, JPEG, PNG, JSON, XML, PDF 등 다양한 종류의 자원을 주고받을 수 있음
- 즉, HTTP는 주고받을 미디어 타입에 특별히 제한을 두지 않고 독립적으로 동작이 가능한 미디어 독립적인 프로토콜
- 미디어 타입은 타입/서브타입(type/subtype) 형식으로 구성
- ex) text/plain, text/html, text/css, text/javascript, image/png...
- *문자를 통해 여러 미디어 타입을 통칭할 수 있음 ex) text/*, image/*, */*
- ;매개변수=값 을 통해 추가적인 정보를 전달할 수도 있음 ex) text/html;charset=UTF-8
스테이트리스 프로토콜
- HTTP는 상태를 유지하지 않는 stateless 프로토콜
- 클라이언트의 모든 HTTP 요청은 기본적으로 독립적인 요청으로 간주
- 상태를 유지하지 않는 특성은 언뜻 효율적이지 않아 보일 수도 있지만, 실제로는 장점이 더 명확함
- 동시에 처리해야 할 요청 메시지의 수가 수천~수백만개가 된다면, 모든 클라이언트의 상태 정보를 유지하는 것은 서버에 큰 부담
- 서버는 하나가 아니라 여러 대로 구성될 경우, 모든 서버가 모든 클라이언트의 상태를 유지할 경우 각 서버마다 클라이언트의 상태를 공유하기 위해 Sync를 하는 것은 큰 부담
- HTTP가 처음 만들어졌을 때부터 오늘날까지 이어지는 중요한 설계 목표
- 확장성(scaleability)
- 견고성(robustness)
- 서버는 하나가 아니라 여러개가 있을 수 있음 -> 상태를 유지하지 않고 모든 요청을 독립적인 요청으로 처리하는 것은 특정 클라이언트가 특정 서버에 종속되지 않도록 하며, 서버의 추가나 문제 발생 시 대처가 용이하도록 함.
- 언제든 쉽게 서버를 추가할 수 있기 때문에 확장성이 높음
- 서버 중 하나에 문제가 생겨도 쉽게 다른 서버로 대처가 가능하기 때문에 견고성이 높음
지속 연결 프로토콜
- HTTP는 지속해서 발전 중인 만큼, 여러 버전이 있음
- 오늘날 많이 사용되는 버전: HTTP 1.1 / HTTP 2.0
- 기본적으로 HTTP는 TCP 위에서 동작
- HTTP는 비연결형 프로토콜, but TCP는 연결형 프로토콜
- 초기의 HTTP버전(1.0 이하)은 3-way handshake를 통해 TCP 연결 수립 후, 요청에 대한 응답을 받으면 연결을 종료하는 방식으로 동작했었음, 추가적인 요청-응답을 하기 위해서는 다시 TCP 연결을 수립해야 했었다[비지속 연결]
(TCP -> HTTP) - 하지만 최근 대중적으로 사용되는 HTTP버전(1.1 이상)은 지속 연결(persistent connection)이라는 기술을 제공함
- 다른 표현으로 킵 얼라이브(kee-aplive)라고도 부름
- keep-alive: 하나의 TCP 연결상에서 여러 개의 요청-응답을 주고 받을 수 있는 기술
HTTP 메시지 구조
[ HTTP 메시지 ]
시작 라인(줄바꿈)
필드 라인* (줄바꿈)
(줄바꿈)
메시지 본문**
------------------
* 0개 이상
** 선택적
- HTTP 메시지는 시작 라인, 필드 라인, 메시지 본문으로 구성
- 필드라인 - 없거나 여러개 있을 수 있음
- 메시지 본문 - 없을 수도, 있을 수도 있음
- 필드 라인과 메시지 본문 사이에는 빈 줄바꿈이 있음
시작 라인(start-line)
- HTTP 메시지는 (HTTP Reqeust 메시지 or HTTP Response 메시지) 일수도 있음
- HTTP 메시지가 요청 메시지일 경우 시작 라인은 '요청 라인'
- HTTP 메시지가 응답 메시지일 경우 시작 라인은 '상태 라인'
- 요청 라인(request-line)
[ 요청 라인 ]
메서드 (공백) 요청대상 (공백) HTTP 버전 (줄바꿈)- 메서드(method): 클라이언트가 서버의 자원(요청 대상)에 대해 수행할 작업을 종류를 나타냄. ex) GET, POST, PUT, DELETE
- 요청 대상(request-target): HTTP 요청을 보낼 서버의 자원을 의미. ex)http://www.example.com/hello?q=world
만약 하위 경로가 없더라도 요청 대상은 슬래시(/)로 표기해야 함. ex)클라이언트가 http://www.example.com으로 요청할 경우 요청 대상은 /가 된다 - HTTP 버전(HTTP-version): 'HTTP/<버전>'이라는 표기 방식을 따름. ex) HTTP 버전 1.1: HTTP/1.1
- 응답 라인(response-line)
[ 상태 라인 ]
HTTP 버전 (공백) 상태 코드 (공백) 이유 구문* (줄바꿈)
-------------------------------------------
* 선택적- HTTP 버전(HTTP-version): 요청과 동일
- 상태 코드(status code): 요청에 대한 결과를 나타내는 세 자리 정수
- 이유 구문(reason phrase): 상태 코드에 대한 문자열 형태의 설명
필드 라인(field-line)
GET /example-page HTTP/1.1
-----------------------------
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101
Firfox/118.0
Accept: text/html
------------------ 아래부터가 HTTP 헤더- 0개 이상의 HTTP 헤더(HTTP header)가 명시
- -> 그래서 이 필드라인을 헤더 라인(header-line)이라 부르기도 함
- HTTP 헤더: HTTP 통신에 필요한 부가 정보
- 필드 라인에 명시되는 각 HTTP헤더는 콜론(:)을 기준으로 헤더 이름과 하나 이상의 헤더 값으로 구성
메시지 본문(message-body)
- HTTP 요청 or 응답 메시지에서 본문이 필요한 경우 이 영역에 명시
- 메시지 본문은 존재하지 않을 수도 있고, JSON 또는 HTML 등 다양한 콘텐츠 타입이 사용될 수도 있음
HTTP/1.1 200 OK
Content-Type: application/json
{
"id": 12345,
"name": "John Doe",
"email": "johndoe@example.com"
}
---------------------------------- JSON
HTTP/1.1 200 OK
Content-Type: text/html
<!DOCTYPE html>
<html>
<head>
<title>Example HTML Page</title>
</head>
<body>
<h1>Welcome to our website</h1>
<p>This is a simple HTML page.</p>
</body>
</html>
---------------------------------- HTMLHTTP 메서드
| HTTP 메서드 | 설명 |
| GET | 자원을 습득하기 위한 메서드 |
| HEAD | GET과 동일하나, 헤더만을 응답받는 메서드(Body 제외) |
| POST | 서버로 하여금 특정 작업을 처리하게끔 하는 메서드 |
| PUT | 자원을 대체하기 위한 메서드 |
| PATCH | 자원에 대한 부분적 수정을 위한 메서드 |
| DELETE | 자원을 삭제하기 위한 메서드 |
| CONNECT | 자원에 대한 양방향 연결을 시작하는 메서드 |
| OPTIONS | 사용 가능한 메서드 등 통신 옵션을 확인하는 메서드 |
| TRACE | 자원에 대한 루프백 테스트를 수행하는 메서드 |
- 주로 사용되는 메서드: GET, HEAD, POST, PUT, PATCH, DELETE
API 문서
- 어떤 URL로 어떤 요청을 받았을 때 서버는 어떻게 응답할 것인가?
- 이를 가장 잘 보여주는 문서: API 문서
- ex) 유튜브 API 예시, 네이버 뉴스 검색 결과 API 예시
HTTP 상태 코드
| 상태 코드 | 설명 |
| 100번대(100~199) | 정보성 상태 코드 |
| 200번대(200~299) | 성공 상태 코드 |
| 300번대(300~399) | 리다이렉션 상태 코드 |
| 400번대(400~499) | 클라이언트 에러 상태 코드 |
| 500번대(500~599) | 서버 에러 상태 코드 |
200번대: 성공 상태 코드
- 200번대 상태 코드는 '요청이 성공했음'을 의미
| 상태 코드 | 이유 구문 | 설명 |
| 200 | OK | 요청이 성공했음 |
| 201 | Created | 요청이 성공했으며, 새로운 자원이 생성되었음 |
| 202 | Accepted | 요청을 잘 받았으나, 아직 요청한 작업을 끝내지 않았음 |
| 204 | No Content | 요청이 성공했지만, 메시지 본문으로 표시할 데이터가 없음 |
300번대: 리다이렉션 상태 코드
- 300번대 상태 코드는 리다이렉션(redirection)과 관련한 상태 코드
- 영구적인 리다이렉션(permanent redirection) / 일시적인 리다이렉션(temporary redirection)으로 구분
| 상태 코드 | 이유 구문 | 설명 |
| 301 | Moved Permanently | 영구적 리다이렉션 - 재요청 메서드 변경될 수 있음 |
| 308 | Permanent Redirect | 영구적 리다이렉션 - 재요청 메서드 변경되지 않음 |
| 302 | Found | 일시적 리다이렉션 - 재요청 메서드 변경될 수 있음 |
| 303 | See Other | 일시적 리다이렉션 - 재요청 메서드 GET으로 변경 |
| 307 | Temporary Redirect | 일시적 리다이렉션 - 재요청 메서드 변경되지 않음 |
400번대: 클라이언트 에러 상태 코드
- 400번대 상태 코드는 '클라이언트에 의한 에러가 있음'을 알려주는 상태 코드
| 상태 코드 | 이유 구문 | 설명 |
| 400 | Bad Request | 클라이언트의 요청이 잘못되었음 |
| 401 | Unauthorized | 요청한 자원에 대한 유효한 인증이 없음 |
| 403 | Forbidden | 요청이 서버에 의해 거부됨 (ex: 접근 권한이 없을 경우) |
| 404 | Not Found | 요청받은 자원을 찾을 수 없음 |
| 405 | Method Not Allowed | 요청한 메서드를 지원하지 않음 |
500번대: 서버 에러 상태 코드
- 500번대 상태 코드의 원인은 '서버'
- 클라이언트가 올바르게 요청을 보냈을지라도 발생할 수 있는 서버 에러에 대한 상태 코드
- 502번 에러는 보통 게이트웨이를 통한 포워드/리버스 프록시를 적용했을 때 자주 발생할 수 있다
ex) httpd(apache web server), nginx - 503번 에러는 서버가 과부하 상태에 있거나 일시적인 점검 상태일때 볼 수 있는 상태 코드이다
| 상태 코드 | 이유 구문 | 설명 |
| 500 | Internal Server Error | 요청을 처리할 수 없음 |
| 502 | Bad Gateway | 중간 서버의 통신 오류 |
| 503 | Service Unavailable | 현재는 요청을 처리할 수 없으나 추후 가능할 수도 있음 |
HTTP의 발전: HTTP/0.9에서 HTTP/3.0까지
HTTP/0.9
- 지금은 거의 사용되지 않는 초창기 HTTP 버전
- 사용 가능한 메서드가 GET뿐이었음
- 요청 메시지는 1줄로 구성되어 있었음
- 헤더가 지원되지 않았음
HTTP/1.0
- HEAD, POST와 같은 GET 이외의 메서드가 도입됨
- 헤더가 지원되기 시작함
- 하지만 여전히 공식적으로는 지속 연결(persistent connection)을 지원하지 않았음
HTTP/1.1
- 공식적으로 지속 연결이 지원
- 파이프라이닝 기능 (특정 요청에 대한 응답이 수신되기 전에 다음 요청을 보낼 수 있는 기능)
- 콘텐츠 협상 기능 추가
- 다양한 편의 기능 및 사용 가능한 헤더가 추가
- 오늘날까지 널리 사용되는 버전
HTTP/2.0
- HTTP/1.1의 효율과 성능을 높이기 위한 버전
- 송수신 효율을 높이기 위해 헤더를 압축하여 전송하는 기능
- 텍스트 기반의 메시지를 송수신한 이전 버전과는 달리 바이너리 데이터 기반의 메시지를 송수신
- 클라이언트가 요청하지 않았더라도 미래에 필요할 것으로 예상되는 자원을 미리 전송해 주는 서버 푸시 기능 제공
- HTTP/1.1까지의 고질적인 문제였던 HOL 블로킹(Head-Of-Line Blocking)이라는 문제를 완화한 버전
- HOL 블로킹: 같은 큐에 대기하며 순차적으로 처리되는 여러 패킷이 있을 때, 첫 번째 패킷의 처리 지연으로 인해 나머지 패킷들의 처리도 모두 지연되는 문제 상황
- 멀티플렉싱(multi-plexing) 기법을 도입해 완화
- HTTP 멀티플렉싱: 여러 스트림(stream)을 이용해 병렬적으로 메시지를 주고받는 메시지
- 요청과 응답을 주고받는 단위는 하나의 스트림에서 처리, 이러한 스트림을 여러 개 활용하는 동시에 스트림별로 독립적인 송수신이 가능하며, 스트림별 메시지들은 꼭 일정한 순서를 유지할 필요가 없음
- 결국, 별도의 스트림을 통해 여러 데이터를 병렬적으로 주고받아서 HOL 블로킹을 상당 부분 완화하는 것
HTTP/3.0
- 이전의 HTTP 버전들은 모두 TCP를 기반으로 동작했다면, HTTP/3.0은 UDP를 기반으로 동작함
- 정확히는 UDP를 기반으로 구현된 QUIC(Quick UDP Internet Connections) 프로토콜을 기반으로 동작
- 연결형 프로토콜인 TCP에 비해 비연결형 프로토콜인 UDP는 상대적으로 더 빠르기 때문에, HTTP/3.0은 속도 측면에서 큰 개선이 이루어짐
- HTTP/3.0은 현재 빠르게 성장하는 프로토콜로, 이에 따라 QUIC의 중요성도 점차 커지는 중
HTTP 헤더
요청 시 활용되는 HTTP 헤더
| 헤더명 | 역할 | 추가설명 | 예시 |
| Host | 요청을 보낼 호스트를 지정 | 주로 도메인 네임으로 명시. 포트번호가 포함될 수 있음 | Host: info.cern.ch |
| User-Agent | 클라이언트 측의 프로그램을 의미 | 운영체제, 브라우저 종류/버전, 렌더링 엔진 등 | User-Agent: Mozilla/5.0(Windows NT 10.0; Wind64; x64) Gecko/20100101 Firefox/109.9 |
| Referer | 클라이언트가 요청을 보낼 때 머무르고 있던 URL | 리다이렉트 되면서 거친 주소지를 파악 가능 영문법적으로 Referrer가 맞지만, 초기 개발 당시의 오타로 Referer가 사용 | Referer: https://en.wikipedia.org/ |
| Authorization | 클라이언트의 인증 정보를 포함 | 인증 타입과 인증을 위한 정보가 차례로 명시 <type> <credentials> | Authorization: Basic bWluY2h1bDox |
응답 시 활용되는 HTTP 헤더
| 헤더명 | 역할 | 추가설명 | 예시 |
| Server | 요청을 처리하는 서버측의 소프트웨어 관련 정보 명시 | Server: Apache/2.4.1 (Unix) | |
| Allow | 클라이언트에게 허용된 HTTP 메서드 목록을 알려주기 위해 사용 | 상태코드 405에 Allow 헤더가 함께 사용 | Allow: POST, OPTIONS |
| Retry-After | 추후에 응답이 가능함을 알리기 위함 | 상태코드 503과 함께 사용 | Retry-After: Fri, 23 Aug 2024 09:00:00 GMT Retry-After: 120 |
| Location | 클라이언트에게 자원의 위치를 알려주기 위해 사용되는 헤더 | 주로 리다이렉션이 발생했을 때나 새로운 자원이 생성되었을 때 사용 | Location: /users/1 |
| WWW-Authenticate | 자원에 접근하기 위한 인증 방식을 설명하는 헤더 | 상태코드 401과 함께 사용 | WWW-Authenticate: Basic WWW-Authenticate: JWT |
요청과 응답 모두에서 활용되는 HTTP 헤더
| 헤더명 | 역할 | 추가설명 | 예시 |
| Date | 메시지가 생성된 날짜와 시각에 관련된 정보를 담은 헤더 | 클라이언트/서버 모두 사용될 수 있는 헤더 | Date: Tue, 15 Nov 1994 08:12:31 GMT |
| Connection | 클라이언트의 요청과 응답간의 연결 방식을 설정하는 헤더 | 지속 연결, 연결 종료를 나타냄 | Connection: keep-alive Connection: close |
| Content-Length | 본문의 바이트 단위 크기(길이)를 나타냄 | Content-Length: 100 | |
| Content-Type | 전송하려는 메시지 본문의 표현 방식을 설명하는 헤더 표현 헤더의 일종이라고도 부름 | 메시지 본문에서 사용된 미디어 타입을 표현 | Content-Type: text/html; charset=UTF-8 |
| Content-Language | 전송하려는 메시지 본문의 표현 방식을 설명하는 헤더 표현 헤더의 일종이라고도 부름 | 메시지 본문에 사용된 자연어를 명시 | Content-Language: ko-KR Content-Language: en-US Content-Language: en-GB |
| Content-Encoding | 전송하려는 메시지 본문의 표현 방식을 설명하는 헤더 표현 헤더의 일종이라고도 부름 | 메시지 본문을 압축하거나 변환된 방식이 명시 | Content-Encoding: gzip Content-Encoding: compress Content-Encoding: deflate Content-Encoding: br |
언어코드와 국가코드
언어코드와 국가코드를 혼합해서 사용: 언어코드-국가코드
ex) ko-KR(한국어, 한국에서 사용하는), en-US(영어, 미국에서 사용하는), en-GB(영어, 영국에서 사용되는)
- 언어코드
- 한국어: ko
- 영어: en
- 중국어: zh
- 일본어: ja
- 독일어: de
- 프랑스어: fr
- 국가코드
- 한국: KR
- 미국: US
- 영국: GB
- 중국: CN
- 타이완: TW
- 일본: JP
- 독일: DE
- 프랑스: FR
캐시
캐시(Cache)
- 불필요한 대역폭 낭비와 응답 지연을 방지하기 위해 정보의 사본을 임시로 저장하는 기술
- 정보의 사본을 임시로 저장하는 것 자체를 캐시(cache)한다, 캐싱(caching)한다 라고도 표현하며, 캐시된 데이터를 캐시라 부름
- 개인 전용 캐시(private cache): 웹 브라우저에 저장된 캐시
- 공용 캐시(public cache): 클라이언트와 서버 사이에 위치한 중간 서버에 저장된 캐시
캐시 신선도(Cache Freshness)
- 캐시된 사본 데이터가 얼마나 최신 원본 데이터와 유사한지를 나타내는 정도
- 신선도를 유지하는 가장 기본적인 방법: '캐시된 데이터에 유효 기간을 설정하는 방법'
- 유효기간을 부여하는 방법 - 응답 메시지의 헤더 사용
- Expires 헤더(날짜)
- Cache-Control 헤더의 Max-Age 값(초)
- Etag / 엔티티 태그 / Entity Tag (버전)
HTTP/1.1 200 OK
...
Expires: Tue, 06 Feb 2024 12:00:00 GMT
----
HTTP/1.1 200 OK
...
Cache-Control: max-age=1200
----
GET /index.html HTTP/1.1
Host: www.example.com
If-None-Match: "abc"쿠키(Cookie)
- 서버에서 생성되어 클라이언트 측에 저장되는 데이터
- 상태를 유지하지 않는 Stateless 프로토콜인 HTTP를 보완하기 위한 수단
- 서버가 클라이언트의 상태를 알 수 있게끔 하는 특별한 데이터
- 쿠키는 <key, value> 쌍 형태를 띄고 있음
- 적용 범위와 만료 기간 등 다양한 속성을 갖고 있음
- 서버 -> 쿠키생성 -> 클라이언트에게 전송
- 클라이언트 -> 요청 메시지 + 쿠키 -> 서버에 요청
서버로부터 받은 응답 메시지
Set-Cookie: name=boki
Set-Cookie: phone=010-5555-8888
Set-Cookie: message=Hello다시 서버로 보낼 때 사용하는 요청 메시지
GET /next-page HTTP/1.1
Host: example.com
Cookie: name=boki; phone=5555-8888; message=Hello
...
도메인별로 쿠키 구분
Set-Cookie: name=boki domain=example.com
경로별로 쿠키 구분
Set-Cookie: name=boki path=/study
쿠키의 폐기 날짜 설정(Expires) - 유효 기간
Set-Cookie: sessionID=abc123; Expires=Fri, 23 Aug 2024 09:00:00 GMT
쿠키의 유효시간 설정(Max-Age) - 초 단위
Set-Cookie: sessionID=abc123; Max-AGe=25920000
보안
- Secure: HTTPS 프로토콜이 사용되는 경우만 쿠키를 전송하도록 하는 속성
- HttpOnly: HTTP 송수신을 통해서만 쿠키를 이용하도록 제한하는 속성
(JavaScript를 통해 쿠키에 접근하는 것을 방지 == 악성 스크립트를 통해 쿠키 값에 접근하는 것을 방지)
세션 인증
- 세션 아이디(session id): 쿠키를 통해 전달되는 대표적인 정보
- 세션 인증(session authentication)
- 클라이언트는 서버에게 id, pw와 같은 인증 정보를 전송
- 인증 정보가 올바른 경우, 서버는 세션 아이디를 생성해 클라이언트에게 전송
- 서버는 생성한 세션 아이디를 데이터베이스 혹은 HttpSession 등에 저장
- 클라이언트는 추후 요청을 보낼 때 쿠키 내에 세션 아이디를 포함하여 전송
- 서버는 쿠키 속 세션 아이디와 저장된 세션 아이디를 비교하여 클라이언트를 식별
- 내 말 덧붙임; 종종 쿠키와 세션 인증을 아예 다른 것으로 보는 개발자들이 많은데, 결국 세션 인증을 하려면 쿠키로 세션 아이디를 내려보내줘야 하기때문에 세션 인증은 쿠키와 무관한 방식이 아님!!
웹 스토리지 - (로컬 스토리지 & 세션 스토리지)
- 쿠키 이외에도 클라이언트가 저장하고 클라이언트의 상태를 추측할 수 있는 <키-값> 쌍의 정보
- 웹 스토리지: 웹 브라우저 내의 저장 공간으로, 일반적으로 쿠키보다 더 큰 데이터를 저장 가능
- 웹 스토리지의 정보는 서버로 자동 전송되지 않음
- 종류
- 로컬 스토리지(local storage): 별도로 삭제하지 않는 한 영구적으로 저장이 가능
- 세션 스토리지(session storage): 브라우저가 열려 있는 동안 유지되는 정보(같은 도메인이더라도 새 탭을 열때마다 초기화됨!)
콘텐츠 협상과 표현
한국에서 접속하거나 한국어 계정으로 구글에 접속하면 한국어로 된 웹 페이지를 볼 수 있고, 다른 지역에서 접속하거나 영어 계정으로 같은 URL에 접속하면 영어로 된 웹 페이지를 볼 수 있는 상황을 경험해본 적이 있을 것이다
콘텐츠 협상(Content Negotiation)
- 같은 URI에 대해 가장 적합한 '자원의 형태'를 제공하는 메커니즘을 의미
- 같은 URI로 식별 가능한 HTML 문서라고 해도, 영어로 요청하면 영어로 된 형태로 제공하고, 한국어로 요청하면 한국어로 된 형태를 제공
GET 메서드의 재정의
https://www.rfc-editor.org/rfc/rfc9110.html#name-get
RFC 9110: HTTP Semantics
The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of
www.rfc-editor.org
The GET method requests transfer of a current selected representation for the target resource.- as-is: 자원을 습득하기 위한 메서드
- to-be: 자원의 특정 표현을 습득하기 위한 메서드
표현(Representation)
- 송수신 가능한 자원의 형태
- 클라이언트가 선호하는 표현을 반영하고자 콘텐츠 협상 관련 HTTP 헤더들이 사용
- 주요 헤더 종류
- Accept
- Accept-Language
- Accept-Charset
- Accept-Encoding
- ex) 선호하는 언어: 한국어, HTMl 문서 타입을 선호하는 경우
[ 요청 메시지 ]
GET /index.html HTTP/1.1
Host: example.com
Accept-Language: ko
Accept: text/html- 선호도에 우선순위 반영 가능
- 우선순위는 콘텐츠 협상 관련 헤더의 q값으로 표현(q: Quality Value)
- 특정 표현을 얼마나 선호하는지를 나타내는 값
- 생략되었을 경우 1을 의미
- 범위: 0~1
- 값이 클 경우 우선순위가 높음
- ex) 한국어(ko-KR, ko), 영어(en-US, en)순으로 선호하고, HTML, XML, 일반 텍스트 순으로 선호하는 경우
[ 요청 메시지 ]
GET /index.html HTTP/1.1
Host: example.com
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
Accept: text/html,application/xml;q=0.9,text/plain;q=0.6,*/*;q=0.5숙제
Ch.05(05-1) 확인 문제 1번(p.271), (05-2) 확인 문제(p.307) 풀고 설명하기
Q. 도메인 네임과 네임 서버에 대한 설명으로 옳지 않은 것을 골라보세요.
1) 8.8.8.8은 대표적인 공개 DNS 서버로, 구글이 관리합니다.
2) 도메인 네임은 호스트를 특정할 수 있는 문자열 형태의 정보입니다.
3) DNS는 계층적이고 분산된 도메인 네임에 대한 관리 체계이자 이를 관리하는 프로토콜입니다.
4) www.example.com에서 루트 도메인은 com에 해당합니다.A. 4번
Root 도메인은 생략된 .이다
사실상 www.example.com로 접속하는 것은 www.example.com(.)으로 접속하는 것과 같다!
.com은 TLD(Top Level Domain)이다
Q. HTTP 상태 코드에 대한 설명으로 옳지 않은 것을 골라보세요.
1) 300번대 상태 코드는 요청한 자원이 존재하지 않음을 의미합니다.
2) 400번대 상태 코드는 클라이언트에 의한 에러를 의미합니다.
3) 500번대 상태 코드는 서버에 의한 에러를 의미합니다.
4) 200번대 상태 코드는 요청이 성공했음을 의미합니다.A. 1번
300번대 상태코드는 리다이렉션 상태 코드이다
요청한 자원이 존재하지 않는 상태 코드는 400번대의 404 에러이다.
추가숙제
HTTP 요청 메시지 확인해보기
개발자 도구 열기: 윈도우에서는 F12, 맥에서는 cmd + option + I 또는 Fn(펑션키) + F12
네이버로 들어가서 개발자 도구를 확인해봤다
참고로 웹 개발자라면 반드시 알아야 될 지식으로.. 개발자도구 네트워크 탭에서 Fetch/XHR을 체크해야 API만 필터링 해서 볼 수 있다
이 중에서 auth요청을 확인해봤는데, POST(Http Method)로 요청을 했고 상태코드가 200으로 응답을 성공했다는 것을 알 수 있었다
후기
이번에는 일반인, 개발자 포함 우리 모두한테 가장 친숙한, 응용 계층을 공부해봤다
백엔드 개발자는 HTTP Status 부분에서 친숙함을 느꼈을 것이고, 프론트엔드 개발자는 개발자 도구에서 친숙함을 느꼈을 것 같다
책을 거의 완독해간다.. 이제 100쪽 조금 덜 남았는데, 앞으로 힘 내서 달려본다!!
사실 약간 아쉬웠던 포인트는 로컬 스토리지와 세션스토리지에 대해서 조금 더 부가적인 설명이 있었으면 했다
< 세션 스토리지에 데이터를 저장하면 같은 주소로 접속했더라도 새로운 탭을 만들어서 접속하면 데이터가 달라진다 >는 특징도 넣어줬음 했다
추가로 다국어를 지원하기 위한 부가적인 내용으로 i18n(internationalization)이나 HTTP 주소에서 좀 더 사용자를 위한 표현 방식인 RESTful, HateOS, 그리고 CORS도 나왔으면.. 아주 쬐끔 아쉬웠다
하지만 개발책이 아니고 네트워크 책이니까 괜찮다!!!
그리고 쿠버네티스에서도 IP기반이 아닌 DNS기반으로 접속을 만드는 경우가 많기 때문에 DNS와 관련 명령어 학습을 추천한다!
DNS 레코드 타입도.. 내가 근무한 첫 회사에서 도메인을 관리하고 인증서를 관리해주는 유료 사이트에서 등록하는 업무를 맡을 때 나왔던 개념이었다!!
또 내 블로그로 같이 공부를 하는 사람들이 있다면 로컬스토리지vs세션스토리지, i18n, RESTful, HateOS 키워드로 검색해서 추가적인 공부를 해보는 것도 추천한다
네트워크에 대해 공부하면 할수록 더 깊이있어지는것 같아서 정말 좋다~!!
그리고 한빛미디어를 통해 지금 혼공단을 하면서 동시에 한빛미디어의 여러 행사도 참여하고 있는데...
거기에서 받은 고양이 웹캠커버이다! 2개를 받아서 하나는 지인 주고 하나는 내 노트북에 달아놓았다
다른분들도 한빛미디어x한빛앤 등 여러 강연이나 행사에 참여해서 좋은 경험을 얻으면 좋겠다..쿠쿠
ㅋㅋㅋㅋ 넘 귀여워!!!
이제 남은 마지막주도 힘내서 잘 마무리해보고, 복습도 꾸준히 해서 현업에서 내가 공부한 지식들을 잘 녹여냈으면 좋겠다
화이팅!!!
책 구매처
https://www.yes24.com/Product/Goods/125830483
혼자 공부하는 네트워크 - 예스24
혼자 해도 충분하다!1:1 과외하듯 배우는 네트워크 자습서『혼자 공부하는 네트워크』는 개발자의 필수 지식인 네트워크를 기본부터 제대로 학습할 수 있도록 돕는 입문서이다. 다수의 네트워
www.yes24.com
댓글