🔭

google.com 입력 후

1. presentation

2. ver. 20min

1. presentation

OSI Model, LAN, WAN 중심으로 본 주제를 20분간 발표했습니다.

발표 자료: Presentation Slide in Web

참고) 발표 이미지

2. ver. 20min

가. 핵심 내용

1) OSI Model

2) Switching

3) Routing

4) Browser Rendering

5) HTTPS

6) CDN

나. Client Node

1) 응용 계층

이하에서 HTTP 처리 과정 참고

HTTP Network Basic - 우에노 센

•

브라우저는 ‘google.com’을 입력 받으면 이를 바탕으로 HTTP Request를 생성한다. 특히 헤더의 ‘Request Line’에 URI, 메소드, 버전 필드에 각각 google.com, GET, HTTP 1.1이 입력된다.

2) 표현 계층

•

인코딩: HTTP Header의 Content-Type에 콘텐츠 타입을 지정하고, Content-Encoding에 해당 콘텐츠에 대한 인코딩 방식을 입력하여 사용한다. Content-Encoding 헤더에 gzip, compress, deflate 등의 인코딩 방식을 입력하여 지정된 콘텐츠 타입의 데이터(message payload)를 압축할 수 있다.

•

암호화: HTTPS(SSL/TLS 프로토콜)를 사용하여 데이터를 암호화한다. HTTPS는 HTTP 통신을 하는 소켓 계층(Secure Socket Layer)에 보안 기술을 추가한 것으로, SSL/TLS 프로토콜을 통해 Client Node와 Web Server 간 통신 데이터를 암호화하여 보안을 강화한다.

3) 세션 계층

•

쿠키 관리(Cookie Management): HTTP는 클라이언트에 대한 정보를 저장하는 데 쿠키(cookie)를 사용한다. 쿠키는 클라이언트 측에서 생성되어 서버에 전송되고, 서버는 클라이언트에게 응답할 때 클라이언트에게 쿠키를 저장하도록 지시한다. 이후 클라이언트는 저장된 쿠키를 서버에 전송하여 세션 관리 등을 수행한다.

참고) 쿠키 보안성 보완 속성

•

Secure: Secure 쿠키는 HTTPS 프로토콜을 통해서만 전송되도록 하는 기능이다. 따라서 중간에 쿠키를 탈취하는 공격을 막을 수 있다.

•

HttpOnly: HttpOnly 쿠키는 자바스크립트를 통해서 쿠키에 접근할 수 없도록 하는 기능이다. 따라서 XSS 공격에 취약하지 않다.

•

SameSite: SameSite 쿠키는 쿠키가 같은 사이트에서만 전송될 수 있도록 하는 기능이다. 따라서 Cross-site request forgery(CSRF) 공격을 막을 수 있다.

•

쿠키 만료 시간 설정: 쿠키의 만료 시간을 설정하여 보안을 강화할 수 있다. 만료 시간을 설정하면 쿠키가 일정 시간이 지나면 자동으로 삭제되므로, 탈취당한 경우에도 일정 시간 이후에는 쿠키를 사용할 수 없다.

4) 전송 계층

•

세그먼트 구성: 7계층에서 생성된 데이터에 ‘TCP 헤더’를 붙여서 ‘세그멘트’를 구성한다. ‘TCP 헤더’에는 가상의 통신로를 확보하는 과정에서 필요한 값이 추가된다.

•

3-way handshaking:  본격적인 데이터 통신 전에 신뢰성이 보장된 가상의 통신로를 확보하는 사전 절차이다. 이 절차는 ‘연결 요청’, ‘연결 요청 + 응답’, ‘연결 응답’의 세 가지 과정을 거친다. 앞의 세 가지 과정은 ‘TCP 헤더’의 ‘코드 비트’의 값을 활용하여 이루어지는데, 연결 요청과 연결 응답은 각각 ‘TCP 헤더’의 ‘코드비트’ 중 SYN, ACK 비트의 값이 1로 변경됨으로써 상대 node에게 전달된다.

5) 네트워크 계층

•

IP 패킷 구성: 4계층에서 생성된 ' 세그먼트’에 ‘IP 헤더’를 붙여서 ‘IP 패킷’(이하 패킷)을 구성한다. IP 헤더에는 송수신처의 IP 주소가 들어가는데, 수신처의 IP 주소는 ‘DNS Lookup’ 과정을 통해 얻고, 송신처의 IP 주소는 DHCP를 통해 얻는다. 

•

DNS Lookup: 우선 Client Node 내 hosts file, DNS 캐시에서 도메인 이름에 맵핑된 IP 주소를 찾아본다. 만약 발견되지 않았다면 ISP에서 자동 할당 받은 로컬 DNS 서버로부터 IP 주소를 찾는다. 로컬 DNS 서버에도 없다면, 로컬 DNS 서버는 Root DNS 서버로부터 com 담당 Top Level DNS Server의 위치를 전달 받고, Top Level DNS 서버로부터 google 담당 Second Level DNS Server의 위치 정보를 전달 받는다. 마지막으로 로컬 DNS 서버가 ‘google’ 담당 Second Level DNS 서버에게 ‘google.com’에 맵핑된 IP 주소를 질의하고 해당 주소를 전달 받는다. 로컬 DNS 서버는 전달 받은 IP 주소로 정상 접속이 되면 client node에게 해당 주소를 전달한다. 

참고) 도메인 질의 순서: Client Node → Local DNS Server → Root DNS Server → Top Level DNS Server → Second Level DNS Server → Sub DNS Server

6) 데이터 링크 계층

•

이더넷 프레임 구성: 3계층에서 생성된 패킷에 ‘이더넷 헤더’를 붙여서 ‘이더넷 프레임’(이하 프레임)을 구성한다. ‘이더넷 헤더’에는 송수신처의 MAC 주소가 들어가는데, 송신처의 MAC 주소는 NIC 장착 시 자동으로 확인 가능하고, 수신처의 MAC 주소는 ARP 테이블에서 수신처 IP주소에 맵핑된 값으로 확인할 수 있다. 

•

수신처 MAC 주소 확인: Client Node 내 ARP 테이블에 수신처 MAC 주소가 없다면 ARP Request를 브로드캐스팅하여 수신처 IP 주소에 맵핑된 MAC 주소를 전달 받는다. 만약 수신처가 같은 네트워크에 존재한다면 수신처 IP 주소에 맵핑된 MAC 주소를 얻을 수 있지만, 다른 네트워크에 존재한다면 디폴트 게이트웨이의 MAC 주소를 대신 얻는다.

7) 물리 계층

•

데이터 링크 계층을 거쳐 생성된 프레임은 NIC를 통해 비트열의 데이터에서 전기신호로 변환된다. 전기신호로 변환된 데이터는 이후 Switch와 Router와 같은 네트워크 장비를 거쳐 WAS에 도달한다.

다. LAN & WAN

1) Trace Route 기반 패킷 이동경로 분석

•

IP Analyzer로 각 IP별 분석

•

192.*.*.1 Private IP

•

211.*.*.1: Public IP

•

100.71.22.93: IANA (Internet Assigned Numbers Authority) 

•

142.250.207.110: Google IP

참고) Trace Route 명령

# 명령 및 옵션 설명
traceroute -n -w 1 -q 1 google.com
-n: DNS Look UP 비활성화
-w: 응답 패킷 수신 시간(단위: 초, 기본값: 5)
-q: HOP 당 traceroute 수행 빈도(기본값: 3)
Plain Text
복사

# 결과
traceroute to google.com (142.250.207.110), 64 hops max, 52 byte packets
192.*.*.1  1.960 ms
*
211.*.*.1  13.222 ms
100.71.22.93  5.077 ms
100.71.34.125  2.463 ms
10.44.252.205  2.432 ms
10.222.23.66  2.648 ms
10.222.23.203  2.970 ms
142.250.162.182  35.348 ms
*
108.170.243.97  38.864 ms
108.170.242.209  34.618 ms
216.239.62.240  41.824 ms
142.250.229.250  39.474 ms
142.250.207.110  31.203 ms
Plain Text
복사

참고) 공인 IP 확인 명령

curl ifconfig.me
Shell
복사

라. CDN Server

1) CDN Server

•

정적 데이터가 CDN Server로 Routing되도록 설정되었다면 CDN Server에서 해당 데이터의 Caching 여부를 확인한다. Caching 되어 있다면 CDN Server로부터 데이터를 받는다. Caching 되어 있지 않다면 데이터는 원본 서버에서 데이터를 받는다

•

예를 들어, 이하의 이미지에서 ‘키보드’에 해당하는 이미지를 google CDN 서버(gstatic)에서 가져온다. 실제로 google.com 요청에 대한 응답에 정적 파일 중 일부가 CDN 서버로부터 전달되는 것을 확인할 수 있다. 다음의 경로를 통해 ‘키보드’에 대한 이미지가 전달된다. https://www.gstatic.com/inputtools/images/tia.png

참고) 구글 메인 이미지

2) Caching

•

추후 데이터가 원본 서버를 거쳐 Client Node로 돌아갈 때, CDN Server를 거친다. 이 때, 원본 서버로부터 얻은 정적 데이터를 CDN Server에 반환한다. 해당 데이터의 Caching 기간은 HTTP Response Header의 TTL 값을 참조하여 결정한다.

마. Web Server

1) 응용 계층

•

Web Server Node에 도달한 데이터는 2, 3, 4 계층의 헤더를 제거하는 역캡슐화 과정을 거쳐 HTTP Request로 변환된다.

•

Web Server는 HTTP Request를 처리한 결과로 HTTP Response를 생성한다. HTTP Response는 캡슐화 과정을 거쳐 Client Node로 전송된다.

사. Browser Rendering

1) Rendering(in 응용계층)

•

이후 데이터는 LAN과 WAN의 영역을 지나고, 역캡슐화의 과정을 거쳐 HTTP Response의 형태로 Web Browser에 도달한다. 

•

렌더링 엔진은 HTTP Response 내 HTML 파일과 CSS 파일을 파싱해서 각각 DOM과 CSSOM을 생성한다. 이후 DOM과 CSSOM을 바탕으로 렌더 트리를 생성한다.

•

자바스크립트 엔진은 HTTP Response 내 Javascript 파일을 파싱해서 이미 생성된 렌더 트리를 동적으로 재결합한다.

•

렌더링 엔진은 생성된 Render Tree를 기반으로 화면에 페인팅한다.

참고) Browser Rendering 용어 정리

•

DOM(Document Object Model): HTML 파일 바탕으로 Object 생성 후 Tree 구조로 변환한 것

•

CSSOM(CSS Object Model): DOM과 같은 트리 구조로, DOM에 CSS 파일을 바탕으로 스타일 정보가 추가된 것

•

Render Tree: DOM과 CSSOM을 바탕으로 브라우저에 필요한 노드만 남기는 방향으로 결합된 것

3. ver. 10min

가. 핵심 내용

1) OSI Model 1, 2, 3, 4, 7 계층

2) Switching

3) Routing

4) Browser Rendering

나. Client Node

1) 응용 계층

•

브라우저는 ‘google.com’을 입력 받으면 이를 바탕으로 HTTP Request를 생성한다. 특히 헤더의 ‘Request Line’에 URI, 메소드, 버전 필드에 각각 google.com, GET, HTTP 1.1이 입력된다. 

2) 전송 계층

•

세그먼트 구성: 7계층에서 생성된 데이터에 ‘TCP 헤더’를 붙여서 ‘세그멘트’를 구성한다. ‘TCP 헤더’에는 가상의 통신로를 확보하는 과정에서 필요한 값이 추가된다.

•

3-way handshaking:  본격적인 데이터 통신 전에 신뢰성이 보장된 가상의 통신로를 확보하는 사전 절차이다. 이 절차는 ‘연결 요청’, ‘연결 요청 + 응답’, ‘연결 응답’의 세 가지 과정을 거친다. 앞의 세 가지 과정은 ‘TCP 헤더’의 ‘코드 비트’의 값을 활용하여 이루어지는데, 연결 요청과 연결 응답은 각각 ‘TCP 헤더’의 ‘코드비트’ 중 SYN, ACK 비트의 값이 1로 변경됨으로써 상대 node에게 전달된다.

3) 네트워크 계층

•

IP 패킷 구성: 4계층에서 생성된 ' 세그먼트’에 ‘IP 헤더’를 붙여서 ‘IP 패킷’(이하 패킷)을 구성한다. IP 헤더에는 송수신처의 IP 주소가 들어가는데, 수신처의 IP 주소는 ‘DNS Lookup’ 과정을 통해 얻고, 송신처의 IP 주소는 DHCP를 통해 얻는다. 

•

DNS Lookup: 우선 Client Node 내 hosts file, DNS 캐시에서 도메인 이름에 맵핑된 IP 주소를 찾아본다. 만약 발견되지 않았다면 ISP에서 자동 할당 받은 로컬 DNS 서버로부터 IP 주소를 찾는다. 로컬 DNS 서버에도 없다면, 로컬 DNS 서버는 Root DNS 서버로부터 com 담당 Top Level DNS Server의 위치를 전달 받고, Top Level DNS 서버로부터 google 담당 Second Level DNS Server의 위치 정보를 전달 받는다. 마지막으로 로컬 DNS 서버가 ‘google’ 담당 Second Level DNS 서버에게 ‘google.com’에 맵핑된 IP 주소를 질의하고 해당 주소를 전달 받는다. 로컬 DNS 서버는 전달 받은 IP 주소로 정상 접속이 되면 client node에게 해당 주소를 전달한다. 

참고) 도메인 질의 순서: Client Node → Local DNS Server → Root DNS Server → Top Level DNS Server → Second Level DNS Server → Sub DNS Server

4) 데이터 링크 계층

•

이더넷 프레임 구성: 3계층에서 생성된 패킷에 ‘이더넷 헤더’를 붙여서 ‘이더넷 프레임’(이하 프레임)을 구성한다. ‘이더넷 헤더’에는 송수신처의 MAC 주소가 들어가는데, 송신처의 MAC 주소는 NIC 장착 시 자동으로 확인 가능하고, 수신처의 MAC 주소는 ARP 테이블에서 수신처 IP주소에 맵핑된 값으로 확인할 수 있다. 

•

수신처 MAC 주소 확인: Client Node 내 ARP 테이블에 수신처 MAC 주소가 없다면 ARP Request를 브로드캐스팅하여 수신처 IP 주소에 맵핑된 MAC 주소를 전달 받는다. 만약 수신처가 같은 네트워크에 존재한다면 수신처 IP 주소에 맵핑된 MAC 주소를 얻을 수 있지만, 다른 네트워크에 존재한다면 디폴트 게이트웨이의 MAC 주소를 대신 얻는다.

5) 물리 계층

•

데이터 링크 계층을 거쳐 생성된 프레임은 NIC를 통해 비트열의 데이터에서 전기신호로 변환된다. 전기신호로 변환된 데이터는 이후 Switch와 Router와 같은 네트워크 장비를 거쳐 WAS에 도달한다.

다. LAN & WAN

1) Switching 일반

•

Switch는 ‘MAC 주소 필터링’ 방식으로 프레임을 전송한다. 다시 말해, ‘MAC 주소 테이블’를 참고하여 이더넷 헤더의 수신처 MAC 주소에 맵핑된 포트로 프레임을 전달한다. 

2) LAN → WAN

•

프레임이 WAN 구간으로 전달될 경우, Switch의 ‘기본 게이트웨이’를 거쳐 Router로 전달된다.  

3) Routing 일반

•

Router는 IP 주소를 참고하여 패킷을 전송한다. 다시 말해, ‘라우팅 테이블’를 참고하여 수신처 IP 주소에 맞는 경로로 패킷을 전달한다.  

라. Web Server

1) 응용 계층

•

Web Server Node에 도달한 데이터는 2, 3, 4 계층의 헤더를 제거하는 역캡슐화 과정을 거쳐 HTTP Request로 변환된다.

•

Web Server는 HTTP Request를 처리한 결과로 HTTP Response를 생성한다. HTTP Response는 캡슐화 과정을 거쳐 Client Node로 전송된다.

마. Browser Rendering

1) Rendering(in 응용계층)

•

이후 데이터는 LAN과 WAN의 영역을 지나고, 역캡슐화의 과정을 거쳐 HTTP Response의 형태로 Web Browser에 도달한다. 

•

렌더링 엔진은 HTTP Response 내 HTML 파일과 CSS 파일을 파싱해서 각각 DOM과 CSSOM을 생성한다. 이후 DOM과 CSSOM을 바탕으로 렌더 트리를 생성한다.

•

자바스크립트 엔진은 HTTP Response 내 Javascript 파일을 파싱해서 이미 생성된 렌더 트리를 동적으로 재결합한다.

•

렌더링 엔진은 생성된 Render Tree를 기반으로 화면에 페인팅한다.

참고) 기본 용어 정리

•

DOM(Document Object Model): HTML 파일 바탕으로 Object 생성 후 Tree 구조로 변환한 것 

•

CSSOM(CSS Object Model): DOM과 같은 트리 구조로, DOM에 CSS 파일을 바탕으로 스타일 정보가 추가된 것

•

Render Tree: DOM과 CSSOM을 바탕으로 브라우저에 필요한 노드만 남기는 방향으로 결합된 것

4. ver. 3min

가. 핵심 내용

1) OSI Model 2, 3, 4, 7 계층

2) Browser Rendering

나. Client Node

1) 응용 계층

•

브라우저는 ‘google.com’을 입력 받으면 이를 바탕으로 HTTP Request를 생성한다. 참고로 ‘google.com’은 HTTP Request Header의 ‘Request URI’ 필드에 입력된다.

•

HTTP Request는 네트워크 통신을 위해 4, 3, 2 계층별로 헤더가 붙는 캡슐화 과정을 거친다.

2) 전송 계층

•

전송 계층에서는 ‘TCP 헤더’가 추가된다. TCP 헤더에는 가상의 통신로를 확보하는 과정에 필요한 값이 추가된다. 대표적인 예로 3-way handshaking에 필요한 값들이 헤더 내 ‘코드 비트 영역’에 추가된다. 

3) 네트워크 계층

•

네트워크 계층에서 ‘IP 헤더’가 추가된다. IP 헤더에는 송수신처의 IP 주소가 포함된다. 수신처의 IP 주소는 DNS Lookup 과정을 통해 획득할 수 있다. 송신처의 IP 주소는 DHCP를 통해 획득할 수 있다.

4) 데이터링크 계층

•

데이터링크 계층에서 ‘이더넷 헤더’가 추가된다. 이더넷 헤더에는 송수신처의 MAC 주소가 포함된다. 수신처의 MAC 주소는 ARP 테이블에서 확인할 수 있다. 송신처의 MAC 주소는 랜 카드 장착 시 자동으로 확인할 수 있다.

다. LAN & WAN

•

이후 데이터는 송수신처의 IP주소와 MAC 주소를 바탕으로 Switch와 Router를 거쳐 WAS로 전송된다.

라. Web Server

•

Web Server Node에 도달한 데이터는 2, 3, 4 계층의 헤더를 제거하는 역캡슐화 과정을 거쳐 HTTP Request로 변환된다. 

•

Web Server는 HTTP Request를 처리한 결과로 HTTP Response를 생성한다. HTTP Response는 캡슐화 과정을 거쳐 Client Node로 전송된다.

마. Browser Rendering

•

이후 HTTP Response는 LAN과 WAN의 영역을 지나고, 역캡슐화의 과정을 거쳐 Web Browser에 도달한다. Web Browser는 HTTP Response 내 HTML, CSS, JS 등의 소스를 바탕으로 렌더링하여 시각적인 결과물을 출력한다.

Reference

•

미즈구치 카츠야, 모두의 네트워크

•

아미노 에이지, 네트워크 교실

•

우에노 센, HTTP & Network Basic

•

Alex Xu, System Design Interview

•

MDN, 브라우저 동작 방식, https://developer.mozilla.org/en-US/docs/Web/Performance/How_browsers_work

•

MDN, HTTP Session, https://developer.mozilla.org/en-US/docs/Web/HTTP/Session

•

김형업, TCP/IP 네트워크 스택 이해하기, https://d2.naver.com/helloworld/47667

•

Nisal Pubudu, Understanding HTTP Protocol & OSI Model, https://medium.com/geekculture/understanding-http-protocol-osi-model-ba57cd5bda14

•

IP 기반 위치 분석, https://www.ipalyzer.com/

•

TraceRoute, https://www.ibm.com/docs/ko/aix/7.1?topic=analysis-traceroute-command