FrontEnd Roadmap 01 - 인터넷 파트1: 인터넷과 HTTP

SANGHYUN KIM·2024년 10월 13일

frontend-roadmap

목록 보기

1/9

Updated Log

2025.01.05: 인터넷파트 Web Security 기간 변경

2025.01.16: 인터넷파트 Web Security 회차 수정

2025.02.18: 내가 궁금한 모음집부터 이후 회차 제목 수정(TBD)

2025.03.30: 7회차부터 9회차 제목 수정

글또 환경을 빌려 앞으로 FrontEnd Roadmap을 따라서 공부하고 그 내용을 정리하려고 한다.

전체 map을 보면서 다음과같이 구분을 했고 이 순서에 따라서 글을 작성할 것이다.(순서 및 내용 변경 가능)

인터넷 파트1: 인터넷과 HTTP
인터넷 파트2: 브라우저와 DNS
인터넷 파트3: 브라우저 Deep Dive(Render To View)
인터넷 파트4: Web Security 1: OWASP
인터넷 파트5: Web Security 2: CORS, CSP
내가 궁금한 모음집(쿠키(cookies), PWA, Web Components)
Package Manager(npm, pnpm, yarn)
Module Bundlers(Vite, Webpack, Rollup)
내가 궁금한 모음집2탄(Data tag, Web Accessibility)

이 글은 “인터넷과 HTTP”에 대한 내용이다

해당 게시글을 알기 위한 사전 단어

단어	의미
packet	internet으로 전송되는 작은 데이터의 단위
router	서로 다른 네트워크 간에 데이터 패킷을 전달하는 장치
IP Address	네트워크 상에 연결된 각 디바시으 별 유니크한 식별자. 데이터가 정확한 장소로 가기 위해서 사용
Domain Name	웹사이트를 식별하는 데 사용되는 사람이 읽을 수 있는 이름(google.com, naver.com)
DNS(Domain Name System)	웹사이트를 식별하는 데 사용되는 사람이 읽을 수 있는 이름(google.com, naver.com)
HTTP(Hypertext Transfer Protocol)	클라이언트와 서버간 통신에 사용되는 protocol
HTTPS(HTTP Sercure)	HTTP의 암호화된 버전
ISP(Internet Service Provider)	인터넷 서비스를 제공하는 업체. 한국에서는 통신사라고 생각.
Sockets	IP주소와 port의 집합으로 커뮤니케이션의 endpoint를 나타내며 장치 간 연결을 설정하고 응용 프로그램 간에 데이터를 전송하는 데 사용

인터넷이란?

조사한 결과 가장 황당하지만 가장 설득력 있는 정의는 “디바이스 간 데이터를 전송할 수 있는 optical fiber cable”이었다.

우리가 일상에서 사용하는 모든 인터넷은 해저 케이블로 전세계로 연결 되어있다. 심지어 무선은 위성 및 기지국을 통해서 전달받아서 해당 정보를 다시 케이블을 활용하여 데이터를 전송하기에 해당 정의가 부합해 보인다.

이런 물리적인 cable을 통해서 우리는 인터넷이라는 공간을 사용한다.

그럼 이 케이블은 각 지점에 어떻게 도달하고 우리가 사용할 수 있게 될까?

인터넷은 어떻게 작동할까?

MDN - 인터넷은 어떻게 동작하는가?를 기반으로 작성했습니다.

개인 간 개인의 연결을 하는 상황이라면 아래와 같이 두 지점간을 연결하면 된다.

그러나 사용자가 늘어난다면 다음과 같이 연결해야할까?

사용자가 많아질 수록 복잡해질 것이 분명하다.

이 문제를 해결하기 위해 “라우터(router)”라는 소형 컴퓨터를 활용한다. 모든 신호는 중앙에 있는 라우터로 정보와 IP Address를 보내고 해당 정보를 IP 주소가 일치하는 디바이스로 전달한다.

이렇게 연결된 네트워크는 다른 네트워크에 연결된다면 다음과 같이 표현할 수 있다.

이렇게 연결된 인터넷은 다수의 네트워크는 ISP로 전달되고 모뎀을 통하여 전달가능한 정보로 변경되어 전세계로 연결이 된다.

Q.무선 인터넷은 어떻게 연결이 되는 걸까?
이 링크의 글을 간단히 요약한다면 WiFi는 전파를 통해서 데이터를 전송한다. 모바일 디바이스에 있는 무선 어댑터 무선 어댑터는 데이터를 무선 신호로 변환하여 안테나를 통해 전송하고 받는다

HTTP(HTTPS)는 무엇일까?

HTTP는 통신 프로토콜(규약)이다. 규약은 왜 필요할까?

HTTP(규약)가 필요한 이유

서로가 다른 방식으로 이야기하면 우리는 정보를 이해하기 어려울 것이다. 그래서 통일된 방법으로 정보를 전달하면 편하다. 규약을 통해서 웹 브라우저와 서버가 서로 데이터를 주고받기 위해 어떤 방식으로 통신할 지 정해진 규칙이 필요했고 이 방식이 “HTTP”이다.

더해서 HTTPS(보안된 규약)가 필요한 이유

How HTTPS works의 “왜 우리는 HTTPS가 필요할까”를 기반으로 작성했습니다.

그럼 보안된 HTTP는 왜 필요할까? 이유는 개인정보 보호, 데이터 무결성, 식별을 위해서다.

먼저 개인정보 보호 대해서 알아보자.
인터넷에는 돌아다니는 정보가 암호화 되지 않으면 중간에 가로채서 정보를 누구나 알아볼 수 있다. 그래서 개인정보를 보호하기 위해서 규약에 맞게 암호화 되고 전달되어야 한다.

두 번째는 무결성이다.
암호화 되지 않은 정보 전달은 중간에 누군가 가로채서 변경 할 수 있다. 그래서 프로토콜을 통해서 처리된 정보는 해당 정보가 조작되지 않음 의미한다.

세 번째는 식별이다.
프로토콜에 따라 처리된 메시지는 발신자를 증명해준다. 발신자를 증명해주기에 누가 보냈는지 알고 신원을 보증해줄 수 있다.

HTTP의 요청/응답의 구조

CloudFlare - What is HTTP를 기반으로 작성했습니다

HTTP는 요청과 응답 두 개로 나누어져있고 먼저 요청부터 살펴보려고 한다.

보통 HTTP 요청의 구조는 아래와 같이 구성되어 있다.

HTTP version type
URL
HTTP method
- GET, POST, DELETE, PUT 등과 같은 메서드
  - 이에 대한 자세한 설명은 Http Method 란? (GET, POST, PUT, DELETE)을 보는 것을 추천

HTTP request headers

GET http://www.google.com/ HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: google.com
Cookie: datr=1265876274-[...]; locale=en_US; lsd=WW[...]; c_user=2101[...]

Optional HTTP body: HTTP 요청 시 데이터를 장착하는 장소

HTTP 응답의 구조는 아래와 같이 구성되어 있다.

HTTP status code: 3자리 숫자로 표현되는 응답의 상태 코드
- 1xx Information
- 2xx Success
- 3xx Redirection
- 4xx Client Error
- 5xx Server Errror
HTTP response headers
Optional HTTP body

HTTPS는 어떻게 암호화 처리가 되는 걸까?

그 이전에 암호화에는 두 종류가 존재한다.

How HTTPS works의 “왜 우리는 HTTPS가 필요할까”를 기반으로 작성했습니다.

대칭키

A와 B가 서로 같은 키를 가지고 통신 데이터를 암호화하고 복호화한다.

장단점: 계산 속도가 빠르고 구현이 간단하지만 탈취 당할 시 전부 암호화 및 복호화 가능

비대칭키

A와 B가 서로 각각 공개키 및 개인키를 생성하고 서로 공개키를 공유한다. 이후 A가 B한테 통신 시 B의 공개키로 암호화하고 B는 자신의 개인키로 복호화해서 해석한다

장점으로는 보안이 뛰어나지만 계산 속도가 느리고 구현이 복잡하다

이제 HTTP가 암호화되는 과정을 볼 것이고 해당 과정은 위 비대칭키 방식을 사용한다.

CloudFlare - TLS 핸드셰이크란 무엇일까요?를 기반으로 작성했습니다.

HTTP는 TLS handshake 과정을 통해서 암호화 된다.

[TCP 과정]

소켓 열기
1. 클라이언트는 서버의 IP 주소와 포트 번호를 받아서 TCP 소켓 스트림을 요청
2. 이 과정에서 TCP 연결이 설정되고, 그 이후 TLS 핸드셰이크가 시작

[TLS 과정]

ClientHello 메시지 전송 (클라이언트 → 서버)
1. 클라이언트가 ClientHello 메세지를 서버 쪽으로 전송
2. 이 메세지에는 클라이언트가 지원하는 암호화 방식(Cipher Suites), TLS 버전, 세션 ID 등이 포함되며 주요 목적은 클라이언트가 서버와 사용할 암호화 방법에 대해 협상을 시작하는 것
ServerHello 메시지 응답 (서버 → 클라이언트)
1. 서버는 ServerHello 메시지를 통해 클라이언트가 제안한 것 중에서 선택한 암호화 방식(Cipher Suite)과 TLS 버전을 응답
2. 동시에 서버의 디지털 인증서(서버의 공개 키가 포함된 인증서)가 전달
3. 이 단계에서 서버는 클라이언트에게 인증서를 통해 자신의 신원을 증명하고, 이후 통신에 사용할 암호화 방식과 키 교환 방식을 결정
서버 인증서 검증 (클라이언트 측)
1. 클라이언트는 서버가 제공한 디지털 인증서를 검증
2. 이 인증서는 신뢰할 수 있는 CA(인증기관)에 의해 서명되어 있어야 하며, 클라이언트는 이를 CA 루트 목록과 비교하여 서버가 신뢰할 수 있는지 확인
3. 여기서 중요한 포인트는 클라이언트의 운영체제나 브라우저가 신뢰할 수 있는 CA 목록을 미리 가지고 있음
키 교환
1. TLS 1.2에서는 클라이언트가 서버의 공개 키를 사용해 프리마스터 시크릿을 암호화한 후 서버로 전송
2. 서버는 자신의 개인 키로 이 프리마스터 시크릿을 복호화해, 양쪽 모두 이 시크릿을 바탕으로 대칭 키를 생성
  1. TLS 1.3에서는 Diffie-Hellman 키 교환(또는 ECDHE)을 사용해 클라이언트와 서버가 합의한 방식으로 대칭 키를 생성
  2. 이 방식은 완벽한 전달 보호(PFS, Perfect Forward Secrecy)를 제공해, 세션 종료 후에도 이전 통신을 해독할 수 없도록 보호
Finished 메시지 주고받기
1. 클라이언트는 생성된 대칭 키로 Finished 메시지를 암호화해 서버로 전송
  1. 이 메시지는 "핸드셰이크 완료"의 신호로, 양측 모두 같은 대칭 키를 가지고 있다는 것을 확인하는 마지막 단계
2. 서버도 동일하게 Finished 메시지를 대칭 키로 암호화해서 클라이언트에게 전송
  1. 이 메시지를 성공적으로 복호화하면 양쪽 모두 대칭 키가 일치하는 것을 간주
암호화된 세션 시작
1. 이제 클라이언트와 서버는 대칭 키를 사용해 암호화된 데이터를 주고 받기
2. (HTTPS가 필요한 이유)이 단계부터는 기밀성(암호화)뿐만 아니라, 무결성(변경되지 않음을 보장)과 인증(서버의 신원 보증)이 보장
(추가요쇼): TLS 세션 재개
1. 핸드셰이크가 끝난 이후, 동일한 클라이언트와 서버가 다시 연결할 때는 TLS 핸드셰이크 전체를 다시 할 필요 없이 세션 재개(Session Resumption) 기능을 사용 가능
2. 클라이언트와 서버는 성능을 높이고 다시 빠르게 암호화된 연결을 설정 가능
3. TLS 1.2는 세션 ID를 통해 세션을 재개하고, TLS 1.3은 세션 티켓을 사용해 이 과정이 더욱 간소화