TL;DR

네트워크 프로토콜

HTTP, HTTPS, FTP, DNS, ARP, DHCP

네트워크 주소

MAC 주소, IP 주소

URI vs URL vs URN

• Uniform Resource Identifier : 자원을 고유하게 식별하고 위치를 저장하는 통합 자원 식별자

• Uniform Resource Locator : 리소스가 있는 위치를 지정 (특정 서버의 한 리소스에 대한 구체적인 위치)

• Uniform Resource Name : 리소스에 이름을 부여,이름으로 자원을 특정하여 가리킨다.

URL 입력과 렌더링 과정

1. 사용자가 브라우저의 주소창에 URL을 입력한다.

2. 브라우저는 DNS를 통해 서버의 진짜 주소(IP 주소) 찾기 (캐시 -> DNS 서버)

3. HTTP 프로토콜 사용해 HTTP 요청 메세지 생성

4. SOCKET 라이브러리 통해 TCP/IP로 3-way Handshake 실행해 서버와 연결

5. TCP/IP 연결을 통해 웹 서버에 HTTP 요청 전송

6. 서버는 요청을 처리하고 HTTP 프로토콜 활용해 HTTP 응답 메세지 생성

7. TCP/IP 연결 통해 요청한 사용자에게 HTTP 응답 전송

8. 도착한 HTTP 응답 메세지는 웹 브라우저에 의해 렌더링 되어 사용자에게 화면으로 출력

   a. 서버에서 HTML을 받아온다.

   b. HTML을 구조별로 분류하여 DOM 트리를 생성

   c. CSS 파일과 스타일 요소를 분류하여 CSSOM 트리를 생성

   d. DOM Tree와 CSS Tress를 Render Tree로 조합 (화면에 어떻게 배치할지 요소들의 크기와 위치를 계산)

   e. Render Tree 정보를 통해 어떻게 색칠할지 Painting 과정

   f. 화면에 출력

웹 캐시

• 웹 캐시에 저장해두어 웹 브라우저가 서버에 같은 자원을 요청하지 않도록 한다.
• 캐시 사용시 서버가 쿠키에 cache-control 속성 추가해서 보내기

네트워크 프로토콜

• HTTP : 인터넷에서 하이퍼 텍스트 문서를 전송하기 위해 사용되는 프로토콜 (서버/클라이언트 모델을 따라 데이터를 주고 받기 위한 프로토콜)

  👆 여기서 잠깐!

  하이퍼 텍스트란? 참조(하이퍼 링크)를 통해 독자가 한 문서에서 다른 문서로 즉시 접근할 수 있는 텍스트

• HTTPS : HTTP에 데이터 암호화가 추가된 프로토콜
  • 대칭키 암호화 방식과, 비대칭키 암호화 방식을 모두 사용
• FTP : 컴퓨터 사이의 원활한 파일 전송을 위해 사용되는 프로토콜
  • 보안을 향상시키기 위해 TLS와 결합한 FTPS와 SSH와 결합한 SFTP가 있다.

• DNS : IP 주소와 도메인의 매핑 정보를 관리하는 프로토콜 (도메인 명을 IP주소로 변환)

• ARP : IP 주소를 물리적 네트워크 주소로 대응시키기 위해 사용되는 프로토콜
• DHCP : 호스트의 IP 주소 및 TCP/IP 설정을 클라이언트에 자동으로 제공하는 프로토콜

기본 네트워크 주소들

• MAC 주소 : 하드웨어 주소로 컴퓨터의 물리적 주소를 의미한다.
  • NIC 카드마다 부여된 네트워크 장비 고유의 주소
• IP 주소 : 소프트웨어 주소로 네트워크 주소를 의미한다.
  • 컴퓨터마다 부여된 고유의 주소

URI vs URL vs URN

	URI는 인터넷의 자원을 식별할 수 있는 문자열을 의미한다. 그 중 어떠한 표준을 지켜서 자원을 식별하는 문자열을 URL, URN이라고 한다.

• URL은 어떻게 리소스를 얻을 것이고 어디서 가져와야하는지 명시하는 URI
• URN은 리소스를 어떻게 접근할 것인지 명시하지 않고 경로와 리소스 자체를 특정하는 것을 목표로하는 URI

URI (Uniform Resource Identifier)

• Uniform Resource Identifier
  • Uniform : 리소스를 식별하는 통일된 방식
  • Resource : 자원, URI로 식별할 수 있는 모든 것
  • Identifier : 다른 항목과 구분하는데 필요한 정보

• 자원을 고유하게 식별하고 위치를 저장하는 통합 자원 식별자

• 인터넷에 있는 자원을 고유하게 식별하고 위치를 지정한다.

URL (Uniform Resource Locator)

• Locator : 리소스가 있는 위치를 지정 (특정 서버의 한 리소스에 대한 구체적인 위치)

• 네트워크상에서 웹 페이지, 이미지, 동영상 등 파일이 위치한 정보를 나타낸다.
• FTP, SMTP 등 다른 프로토콜에서도 사용할 수 있다.

URL 구조

• 스키마 : 리소스를 얻기 위해 사용되는 프로토콜
• 자격 정보 : 서버로부터 리소스 취득할 때 필요 (유저명과 패스워드 지정)
• 서버 주소 : DNS명 또는 IP 주소
• 서버 포트 : 서버 접속 대상이 되는 네트워크 포트 번호 지정 (생략하면 디폴트 포트 사용)
• 계층적 파일 패스 : 리소스 식별하기 위한 서버 상의 파일 패스
• 쿼리 : 리소스에 임의의 파라미터 넘겨주기 위해 사용 (옵션)
• 프래그먼트 식별자 : 리소스에서 서브 리소스를 가리키기 위해 사용 (옵션)

https://www.youtube.com/watch?v=RUjG1et23ZM
file://127.0.0.1/Users/username/Desktop/

• 프로토콜 : https , file

• 호스트 주소 : www.youtube.com, 127.0.0.1

• 경로 : watch, Users/username/Desktop

• 쿼리 : v=RUjG1et23ZM

URN (Uniform Resource Name)

• Name : 리소스에 이름을 부여

• 이름으로 자원을 특정하여 가리킨다.
• 흔히 사용되지 않는다.

urn: ietf:rfc:2141 - 'RFC 2141' 문서

👆 여기서 잠깐!

URN은 왜 필요할까요?

URL은 주소이지 실제 이름이 아니라서 특정 시점에 위치한 곳을 알려줍니다. 그래서 리소스의 위치가 옮겨지면 이전의 URL로는 해당 자원을 찾을 수 없게 됩니다. URN은 위치(주소)나 접근법에 대한 명시 없이 리소스에 대해 이야기할 때 사용할 수 있습니다.

예를 들면, ISBN 시스템에서 ISBN 0-486-27557-4은 셰익스피어의 작품 로미오와 줄리엣의 특정 에디션을 지칭합니다. 이를 URN으로 나타내면 urn:isbn:0-486-27557-4으로 표기할 수 있습니다. 단, 이 표기법에는 어디에서 책의 사본을 찾아야 할지에 대한 정보는 포함하고 있지 않습니다.

URL 입력과 렌더링 과정

1. 웹 브라우저에 URL을 입력했을 때의 수행 과정

1. 사용자가 브라우저의 주소창에 URL을 입력한다.

2. 브라우저는 DNS를 통해 서버의 진짜 주소(IP 주소) 찾기

   • 우선 DNS 기록 캐시를 확인 (browser, OS, router, ISP 등 여러 단계의 캐시로 구성)
   • 캐시에 없으면 ISP의 DNS 서버는 DNS query 보내서 해당 URL 갖는 서버의 IP 주소 찾기
     • ISP : Internet Service Provider의 약자로 인터넷을 통한 데이터 전송을 제공하는 업체 (SK, KT, …)

3. HTTP 프로토콜 사용해 HTTP 요청 메세지 생성

4. SOCKET 라이브러리 통해 TCP/IP로 3-way Handshake 실행해 서버와 연결

5. TCP/IP 연결을 통해 웹 서버에 HTTP 요청 전송

   ✅ more information

   페이지에 대해서 묻는다면 GET 요청을, 증명 정보를 입력하거나 폼을 제출한다면 POST 요청을 보낼 것이다. 해당 요청에는 브라우저 식별 정보, TCP 연결 유지를 요청하는 헤더 등의 정보를 담고 있다.

6. 서버는 요청을 처리하고 HTTP 프로토콜 활용해 HTTP 응답 메세지 생성

7. TCP/IP 연결 통해 요청한 사용자에게 HTTP 응답 전송

   ✅ more information

   서버는 요청한 페이지와 상태코드, 인코딩 방식, 캐싱 방법, 프라이빗 정보등을 담아서 응답을 보낸다.

8. 도착한 HTTP 응답 메세지는 웹 브라우저에 의해 렌더링 되어 사용자에게 화면으로 출력

   ✅ more information

   브라우저는 HTML의 뼈대만 렌더링한 뒤, HTML의 태그를 확인하여 이미지, CSS stylesheet, JavaScript 파일과 같은 추가적인 요소에 대한 get 요청을 보내어 받고 표시한다. (static한 파일은 브라우저에 의해 캐시되기 때문에 다음에 동일한 페이지를 방문했을 때 다시 fetch해오지 않아도 된다.)

2. HTTP 응답의 렌더링 과정

HTTP 렌더링이란?

화면에 표시할 웹 페이지를 만드는 것으로 HTML, CSS, 자바스크립트 등 개발자가 작성한 문서가 브라우저에 출력되는 과정을 의미한다.

렌더링 과정

1. 서버에서 HTML을 받아온다.

2. HTML을 구조별로 분류하여 DOM 트리를 생성

3. CSS 파일과 스타일 요소를 분류하여 CSSOM 트리를 생성

4. DOM Tree와 CSS Tress를 Render Tree로 조합

   (화면에 어떻게 배치할지 요소들의 크기와 위치를 계산)

5. Render Tree 정보를 통해 어떻게 색칠할지 Painting 과정

6. 화면에 출력

👆 여기서 잠깐!

누가(무엇이) 렌더링을 해주나요?

모든 웹 브라우저는 렌더링 엔진과 자바스크립트 엔진을 가지고 있습니다.

• HTML, CSS 문서는 렌더링 엔진이,
• 자바스크립트 코드는 자바스크립트 엔진이 읽어내 렌더링합니다.

웹 캐시

• 네트워크를 통해 다운받는 것은 느리고 비싼 자원이기 때문에 웹 브라우저의 로딩 속도가 느려지는 등의 사용자의 불편감을 해소하기 위한 방법.

• 웹 캐시에 저장해두어 웹 브라우저가 서버에 같은 자원을 요청하지 않도록 한다.

• 사용자가 느끼기에 브라우저 로딩 속도가 빨라진다.

  -> 한 번 들어갔떤 웹사이트는 다음에 더 빨리 들어가짐

캐시 적용

• 캐시를 적용하려면 서버 사이드에서 캐시와 관련된 설정을 해야함
  • HTTP 응답 메세지 헤더에 cache-control 이라는 속성 추가 (캐시의 유효한 시간)
• 유효 시간 내에 같은 파일을 재요청하면 서버로 통신하지 않고 웹 캐시에서 데이터를 가져온다.
• 만약 유효 시간이 만료됐다면 서버에 요청해 다시 가져오고, 이때 캐시를 다시 갱신한다.

캐시의 개선

유효 시간이 아니라 서버의 데이터가 변동된 경우에만 데이터를 가져오는게 효과적이지 않을까?

-> 검증 헤더와 조건부 요청 방법 사용하기

Last-Modified, If-Modified-Since

• 첫 요청 시, 서버에서 응답 메세지를 만들 때 헤더에 데이터가 마지막에 수정된 시간을 의미하는 Last-Modified 속성을 추가

• 캐시의 유효 시간이 지나서 데이터를 요청해야 하는데 캐시에 Last-Modified 속성이 있으면 클라이언트는 요청 헤더에 if-modified-since 속성 추가 (최종 수정일)
• 서버는 요청 메세지의 헤더를 통해 캐시 데이터와 서버 데이터의 최종 수정일을 비교
• 일치한다면 304 not modified 응답 메세지 전송

ETag, If-None-Match

• 캐시용 데이터에 임의의 고유한 버전 이름을 달아둔다. (Entity Tag, ETag)
• 데이터가 변경되면 이 이름을 바꿔서 변경한다.

• 첫 요청시, 서버에서 응답 메세지 만들 때 헤더에 Etag 속성 추가
• 유효 시간이 만료되어 데이터를 재요청할 때, 캐시에 Etag 속성이 있다면 요청 헤더에 If-None-Match 속성 추가
• 서버는 캐시의 ETag와 자신의 데이터의 Etag를 비교하고, 같으면 304 not modified 응답 메세지 전송

더 알아보기

• 소켓 라이브러리

• 렌더링
  • Javascript 코드는 body 태그 닫히기 전에 위치하는 것이 렌더링을 방해하지 않아도 좋고, CSS코드는 head 안에 위치해서 렌더링 처리 시에 브라우저가 더 빨리 참고할 수 있게 하는 것이 좋음
• 브라우저의 기본 구조

질문

URL에 https://www.naver.com 을 쳤을 때 일어나는 일에 대해 아는대로 설명해주세요

• url 에 입력된 값을 브라우저 내부에서 HTTP Request 메시지로 만든다. 만들어진 메시지를 웹 서버로 전송한다. 이 때 만들어진 메시지 전송은 브라우저가 직접하는 것이 아니라 OS에 의뢰하여 메시지를 전달한다. 단, OS에 송신을 의뢰할 때는 도메인명이 아니라 ip 주소로 메시지를 받을 상대를 지정해야 하는데, 이 과정에서 DNS 서버를 조회해야 한다.

• 프로토콜 스택이 브라우저로부터 메시지를 받아 패킷 속에 저장한다. 그리고 수신처 주소 등의 제어정보를 덧붙인다. 그 다음 패킷을 LAN 어댑터에 넘긴다. LAN 어댑터는 다음 Hop의 MAC 주소를 붙인 프레임을 전기신호로 변환시킨다. 그리고 신호를 LAN 케이블에 송출시킨다.

• LAN 어댑터가 송신한 프레임은 스위칭 허브를 경유하여 인터넷 접속용 라우터에 도착한다. 라우터는 패킷을 프로바이더(통신사)에게 전달하고 인터넷으로 들어가게 된다.

• 패킷은 인터넷의 입구에 있는 액세스 회선에 의해 POP(통신사용 라우터)까지 운반된다. POP 를 거쳐 인터넷의 핵심부로 들어가게 된다. 수 많은 고속 라우터들 사이로 패킷이 목적지를 향해 흘러가게 된다.

• 패킷은 인터넷 핵심부를 통과하여 웹 서버측의 LAN 에 도착한다. 방화벽이 도착한 패킷을 검사하고 캐시서버가 패킷이 웹 서버까지 가야하는지 가지 않아도 되는지를 판단한다.

• 패킷이 물리적인 웹 서버에 도착하면 웹 서버의 프로토콜 스택은 패킷을 추출하여 메시지를 복원하고 웹 서버 애플리케이션에 넘긴다. 메시지를 받은 웹 서버 애플리케이션은 요청 메시지에 따른 데이터를 응답 메시지에 넣어 클라이언트로 회송한다. 왔던 방식대로 응답 메시지가 클라이언트에게 전달된다.

DNS를 사용하는 이유는?

인터넷은 서버를 유일하게 구분할 수 있는 IP 주소를 사용하게 되는데 이를 일일히 외우지 않아도 DNS 를 사용하여 호스트의 도메인 이름을 호스트의 네트워크 주소로 바꾸거나 그 반대의 변환을 용이하게 하기 때문에 사용합니다

References

• 스터디 정리글

• URL-URI-URN 차이점

• 네트워크-URI-URL-URN

• 캐시와 조건부 요청