www.google.com을 입력하면 일어나는 일 🌐

인터넷 브라우저 주소창에 'www.google.com'을 입력하고 엔터키를 누르는 순간, 눈 깜짝할 사이에 구글 홈페이지가 화면에 나타납니다. 하지만 이 짧은 순간 동안 컴퓨터와 인터넷 세계에서는 어떤 일들이 일어날까요? 마법처럼 느껴지는 이 과정을 함께 살펴봅시다! 🔍

 

1. DNS 조회: 이름을 주소로 바꾸기 🔤➡️🔢

우리가 'www.google.com'이라는 도메인 이름을 입력하면, 브라우저는 이 이름을 컴퓨터가 이해할 수 있는 IP 주소로 변환해야 합니다.

DNS 조회 과정 📚

  1. 브라우저 캐시 확인 🧠
    브라우저는 먼저 "최근에 이 주소를 방문한 적이 있나?" 확인합니다.
  2. 운영체제 캐시 확인 💻
    브라우저에 없다면, 컴퓨터의 운영체제에 저장된 DNS 캐시를 확인합니다.
  3. 라우터 캐시 확인 📶
    여기서도 못 찾으면, 집이나 사무실의 라우터에게 물어봅니다.
  4. ISP의 DNS 서버에 질의 🏢
    라우터도 모른다면, 인터넷 서비스 제공업체(KT, SKT, LG U+ 등)의 DNS 서버에 물어봅니다.
  5. 재귀적 DNS 조회 🌍
    ISP의 DNS 서버는 전 세계 DNS 서버들에게 차례로 물어보며 주소를 찾습니다.
  6. DNS 서버: "안녕, .com 서버야? google.com의 주소를 알고 있니?" .com 서버: "나는 정확한 주소는 모르지만, google.com 담당 서버를 알아!" DNS 서버: "안녕, google.com 서버야? www.google.com의 주소를 알려줄래?" google.com 서버: "응! www.google.com의 IP 주소는 142.250.196.68이야."
  7. 답변 반환 및 캐싱 ✅
    찾은 IP 주소(예: 142.250.196.68)를 브라우저에게 알려주고, 나중을 위해 캐시에 저장합니다.

 

2. TCP 연결 수립: 안전한 대화 시작하기 🤝

IP 주소를 알게 되면, 브라우저는 해당 서버와 안정적인 연결을 맺어야 합니다.

TCP 3-way 핸드셰이크 🔄

브라우저: "안녕! 나랑 대화할 준비 됐어?" (SYN)
서버: "응, 준비 됐어! 너도 준비 됐니?" (SYN-ACK)
브라우저: "응, 나도 준비 완료! 대화 시작하자!" (ACK)

이 과정은 마치 전화 통화를 시작하기 전에 서로 "여보세요?"라고 확인하는 것과 비슷합니다! 📞

 

3. HTTPS/SSL 핸드셰이크: 비밀 대화 준비하기 🔒

요즘 대부분의 웹사이트는 HTTPS를 사용합니다. 구글도 마찬가지죠! 이 과정에서는 암호화된 안전한 연결을 설정합니다.

SSL/TLS 핸드셰이크 🔐

  1. 암호화 방식 협상
    브라우저와 서버가 "어떤 암호화 방식을 사용할까?"라고 상의합니다.
  2. 인증서 검증
    서버가 "나 진짜 구글이야!"라는 디지털 인증서를 보여주고, 브라우저가 확인합니다.
  3. 비밀키 교환
    안전하게 데이터를 주고받기 위한 암호 키를 만들어 교환합니다.

이 과정은 마치 비밀 대화를 나누기 전에 서로 암호를 정하는 것과 같습니다! 🕵️‍♀️

 

4. HTTP 요청: 정보 요청하기 📝

안전한 연결이 수립되면, 브라우저는 서버에게 웹페이지를 요청합니다.

HTTP 요청 예시 📨

GET / HTTP/1.1
Host: www.google.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html,application/xhtml+xml
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8
Connection: keep-alive

이것은 "안녕하세요, 구글! 당신의 메인 페이지를 보여주세요!"라고 말하는 것과 같습니다. 📮

 

5. 서버 처리 및 응답: 정보 받기 📥

구글 서버는 요청을 받고, 적절한 웹페이지를 만들어서 보내줍니다.

HTTP 응답 예시 📬

HTTP/1.1 200 OK
Date: Mon, 07 Apr 2025 12:00:00 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 45673
Connection: keep-alive

<!DOCTYPE html>
<html lang="ko">
<head>
    <title>Google</title>
    <!-- 이하 HTML 내용 -->

서버가 "여기 구글 메인 페이지가 있어요!"라고 대답하는 것과 같습니다. 📦

 

6. 브라우저 렌더링: 화면에 그리기 🎨

브라우저는 받은 HTML, CSS, JavaScript 등을 해석하여 화면에 웹페이지를 그립니다.

렌더링 파이프라인 🖌️

  1. HTML 파싱 & DOM 트리 생성 📑
    HTML 코드를 브라우저가 이해하는 구조(DOM)로 변환합니다.
  2. CSS 파싱 & CSSOM 생성 🎭
    CSS 코드를 해석하여 스타일 정보를 구성합니다.
  3. 자바스크립트 실행 ⚙️
    페이지의 동작을 담당하는 자바스크립트 코드가 실행됩니다.
  4. 렌더 트리 구성 🌳
    DOM과 CSSOM을 합쳐서 "무엇을 어떻게 그릴지"를 정합니다.
  5. 레이아웃(리플로우) 📏
    각 요소의 크기와 위치를 계산합니다.
  6. 페인트 🖼️
    실제로 화면에 픽셀을 그립니다.
  7. 컴포지팅 ✨
    여러 레이어를 합성하여 최종 화면을 만듭니다.

이 과정은 마치 건축가가 설계도(HTML)와 인테리어 계획(CSS)을 가지고 실제 건물을 짓는 것과 비슷합니다! 🏗️

 

요약: 놀라운 여정의 끝 🏁

브라우저 주소창에 'www.google.com'을 입력하고 엔터키를 누른 후, 0.5초도 안 되는 시간 동안 위의 모든 과정이 일어납니다. 이것이 현대 웹 기술의 놀라운 점이죠!

  1. DNS로 이름을 주소로 변환 🔤➡️🔢
  2. TCP로 안정적인 연결 수립 🤝
  3. HTTPS로 암호화된 보안 연결 구성 🔒
  4. HTTP 요청으로 웹페이지 요청 📝
  5. 서버가 요청을 처리하고 응답 전송 📬
  6. 브라우저가 받은 데이터를 해석하고 렌더링 🎨

인터넷이 마법처럼 느껴질 때가 있지만, 사실은 이렇게 정교하고 복잡한 과정들이 순식간에 이루어지는 것입니다. 기술의 발전과 표준화 덕분에 전 세계 어디서나 동일한 웹페이지를 볼 수 있게 되었죠! 🌍✨

 

 

인터넷 창에 www.google.com를 입력하면 무슨 일이 일어나는지 설명해주세요.

첫번째로 DNS 조회가 일어납니다. 사용자가 www.google.com을 입력하면, 브라우저는 먼저 이 도메인 이름을 IP 주소로 변환해야 합니다. 이 과정을 DNS 조회(DNS Lookup)라고 합니다. 브라우저는 캐시된 DNS 기록을 먼저 확인하고, 없으면 로컬 DNS 서버에 요청하여 www.google.com에 해당하는 IP 주소를 얻습니다.

 

두번째로 TCP 연결 수립입니다. IP 주소가 확인되면, 브라우저는 서버와 TCP 연결을 수립합니다. TCP(Transmission Control Protocol)는 데이터를 신뢰성 있게 전달하기 위한 프로토콜입니다. 이 과정에서 브라우저는 서버와 3-way handshake를 수행합니다. 즉, 브라우저가 SYN 패킷을 보내고, 서버가 SYN-ACK 패킷을 보내며, 다시 브라우저가 ACK 패킷을 보내는 과정입니다.

 

세번째로 HTTP 요청입니다. TCP 연결이 수립되면, 브라우저는 HTTP 또는 HTTPS 요청을 보냅니다. 이 요청은 "GET / HTTP/1.1" 같은 형식으로, 웹 페이지를 요청하는 메시지입니다. 만약 HTTPS를 사용할 경우, 이 단계 이전에 SSL/TLS 핸드셰이크도 수행됩니다. 이 과정에서는 브라우저와 서버가 암호화된 연결을 설정하기 위해 보안 인증서를 교환하고, 암호화 키를 협상합니다.

 

네번째로 서버의 응답을 받습니다. 서버는 요청을 받고, 해당 리소스(HTML, CSS, JavaScript, 이미지 등)를 브라우저에게 응답으로 보냅니다. 이 응답은 HTTP 응답 코드(예: 200 OK)와 함께 전달됩니다.

마지막으로 받은 리소스들을 바탕으로 브라우저 렌더링 파이프라인을 진행합니다. DOM과 CSSOM을 생성하고, 렌더 트리를 구성한 뒤, 레이아웃과 페인트 단계를 통해 웹 페이지가 화면에 표시됩니다.

728x90
저작자표시

'1일 1CS(Computer Science)' 카테고리의 다른 글

리액트의 Render Phase와 Commit Phase  (0) 2025.04.08
리액트의 Strict Mode에 대해서 설명해주세요.  (0) 2025.04.07
자바스크립트의 얕은 복사와 깊은 복사 이해하기  (0) 2025.04.07
트랜잭션 격리수준은 무엇인가요?  (0) 2025.04.07
브라우저 렌더링 파이프라인에 대해서 설명해주세요.  (0) 2025.04.04

1. 전제: 웹 페이지가 표시되는 방식

우선 웹 페이지가 어떻게 우리 화면에 표시되는지 이해하는 것이 중요합니다. 이 과정은 마치 식당에서 음식을 주문하는 것과 비슷합니다

  1. 여러분(브라우저)이 서버(식당)에 특정 웹 페이지(메뉴)를 요청합니다.
  2. 서버는 이 요청을 받아 처리한 후 해당 웹 페이지 데이터(음식)를 여러분에게 전송합니다.
  3. 브라우저는 받은 데이터를 해석하여 화면에 표시합니다(음식을 먹습니다).

이 모든 통신 과정에서 사용되는 규칙을 '프로토콜'이라고 하며, HTTP와 HTTPS는 웹에서 가장 널리 사용되는 프로토콜입니다.

 

2. HTTP란?

HTTP(HyperText Transfer Protocol)는 웹에서 정보를 주고받기 위한 통신 규약입니다. 이름에서 알 수 있듯이, 주로 하이퍼텍스트(HTML)를 전송하기 위해 만들어졌지만, 현재는 이미지, 비디오, 오디오 등 다양한 데이터를 전송하는 데 사용됩니다.

쉽게 설명하자면, HTTP는 인터넷이라는 거대한 도시에서 데이터가 이동하는 방식에 관한 '교통 규칙'이라고 생각하면 됩니다. 모든 웹 브라우저와 서버는 이 규칙을 따라 소통합니다.

HTTP의 특징

  • 상태를 유지하지 않음(Stateless): 각 요청은 독립적이며, 서버는 이전 요청을 기억하지 않습니다. 마치 식당에서 매번 주문할 때마다 처음 온 손님처럼 대하는 것과 같습니다.
  • 단순함: 텍스트 기반이므로 사람이 읽고 이해할 수 있습니다.
  • 확장 가능함: 헤더를 통해 추가 기능을 구현할 수 있습니다.

 

3. HTTP 요청

브라우저가 서버에 보내는 메시지를 HTTP 요청이라고 합니다. 이 요청은, 제가 카페에 들어가서 "아메리카노 한 잔 주세요"라고 말하는 것과 비슷합니다. HTTP 요청은 세 부분으로 구성됩니다.

3.1 HTTP 요청: 요청 행

요청 행은 HTTP 요청의 첫 줄로, 다음 세 가지 정보를 포함합니다:

  1. 메서드(Method): 수행할 작업의 종류(GET, POST, PUT, DELETE 등)
  2. URI(Uniform Resource Identifier): 요청 대상의 경로
  3. HTTP 버전: 사용 중인 HTTP 프로토콜의 버전

예시

GET /index.html HTTP/1.1

이것은 "index.html 페이지를 가져와 달라(GET)"는 요청입니다. 실생활에서는 "메뉴판 좀 보여주세요"라고 요청하는 것과 같습니다.

주요 HTTP 메서드

  • GET: 정보를 요청합니다(데이터 조회).
  • POST: 새로운 정보를 제출합니다(데이터 생성).
  • PUT: 기존 정보를 업데이트합니다.
  • DELETE: 정보를 삭제합니다.

3.2 HTTP 요청: 헤더

헤더는 요청에 대한 추가 정보를 제공합니다. 마치 커피를 주문할 때 "설탕은 적게, 우유는 많이 넣어주세요"라고 부가 정보를 전달하는 것과 같습니다.

Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html,application/xhtml+xml
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8

각 헤더의 의미:

  • Host: 요청하는 서버의 도메인 이름
  • User-Agent: 브라우저와 운영체제 정보
  • Accept: 브라우저가 처리할 수 있는 콘텐츠 유형
  • Accept-Language: 사용자가 선호하는 언어

3.3 HTTP 요청: 본문

본문(Body)은 서버로 전송하는 데이터를 포함합니다. GET 요청에는 보통 본문이 없지만, POST 요청에는 폼 데이터와 같은 정보가 포함됩니다.

예를 들어, 로그인 폼을 제출할 때:

username=user123&password=pass456

이것은 마치 주문서에 상세한 요구사항을 적는 것과 같습니다.

 

4. HTTP 응답

서버가 브라우저의 요청에 대해 보내는 메시지를 HTTP 응답이라고 합니다. 이것은 카페에서 "여기 주문하신 아메리카노 나왔습니다"라고 말하며 커피를 건네주는 것과 같습니다.

4.1 HTTP 응답: 상태 행

상태 행은 응답의 첫 줄로, 다음 정보를 포함합니다:

  1. HTTP 버전: 사용 중인 HTTP 프로토콜의 버전
  2. 상태 코드: 요청 처리 결과를 나타내는 숫자 코드
  3. 상태 메시지: 상태 코드에 대한 간략한 설명
HTTP/1.1 200 OK

주요 HTTP 상태 코드

  • 200 OK: 요청이 성공적으로 처리됨 (주문한 커피가 잘 준비됨)
  • 404 Not Found: 요청한 리소스를 찾을 수 없음 (메뉴에 없는 음료를 주문함)
  • 500 Internal Server Error: 서버 내부 오류 (커피 기계가 고장남)
  • 301 Moved Permanently: 요청한 리소스가 영구적으로 이동함 (매장이 이전함)
  • 403 Forbidden: 접근 권한 없음 (직원 전용 구역에 들어가려 함)

4.2 HTTP 응답: 헤더

응답 헤더는 응답에 대한 추가 정보를 제공합니다. 바리스타가 "핫 아메리카노고, 원두는 에티오피아산이에요"라고 설명하는 것과 같습니다.

Date: Mon, 24 Mar 2025 12:28:53 GMT
Server: Apache/2.4.41 (Ubuntu)
Content-Type: text/html; charset=UTF-8
Content-Length: 29253

 

  • Date: 응답이 생성된 날짜와 시간
  • Server: 서버 소프트웨어 정보
  • Content-Type: 응답 본문의 미디어 타입
  • Content-Length: 응답 본문의 크기(바이트)

4.3 HTTP 응답: 바디

응답 본문은 클라이언트에게 전송되는 실제 데이터를 포함합니다. 이것은 요청한 웹 페이지의 HTML, 이미지 파일, JSON 데이터 등이 될 수 있습니다.

<!DOCTYPE html>
<html>
<head>
    <title>환영합니다</title>
</head>
<body>
    <h1>안녕하세요!</h1>
    <p>이것은 예시 웹 페이지입니다.</p>
</body>
</html>

이것은 실제로 주문한 커피를 받는 것과 같습니다.

 

5. HTTPS란? (HTTP와의 차이는?)

HTTPS(HTTP Secure)는 HTTP에 보안 기능을 추가한 프로토콜입니다. 기본적인 작동 방식은 HTTP와 동일하지만, SSL/TLS라는 암호화 프로토콜을 사용하여 데이터를 암호화합니다.

 

HTTP vs HTTPS

HTTP는 데이터를 일반 텍스트로 전송하는 반면, HTTPS는 데이터를 암호화하여 전송합니다. 이 차이는 마치 일반 우편(HTTP)과 보안 봉투에 담긴 등기 우편(HTTPS)의 차이와 같습니다.

HTTPS의 주요 특징과 장점

  1. 데이터 암호화: 제3자가 통신 내용을 읽을 수 없게 합니다. 누군가가 네트워크 통신을 가로채도 암호화된 정보만 볼 수 있어 내용을 알 수 없습니다.
  2. 데이터 무결성: 전송 중 데이터가 변조되지 않았음을 보장합니다. 마치 봉인된 택배 상자에 "개봉 흔적 있음" 표시가 있는지 확인하는 것과 같습니다.
  3. 인증: SSL/TLS 인증서를 통해 웹사이트의 신원을 확인합니다. 사용자는 접속한 사이트가 진짜인지 확인할 수 있습니다. 이것은 마치 공식 매장에서 발급한 영수증을 확인하는 것과 비슷합니다.
  4. 신뢰성 향상: 브라우저는 HTTPS 사이트에 자물쇠 아이콘을 표시하여 보안 연결임을 사용자에게 알립니다.
  5. SEO 우대: 구글 등의 검색 엔진은 HTTPS 웹사이트를 검색 결과에서 우대합니다.

HTTPS 작동 방식

  1. 핸드셰이크(Handshake): 클라이언트와 서버가 서로를 인증하고 어떤 암호화 방식을 사용할지 결정합니다.
  2. 인증서 확인: 서버는 신뢰할 수 있는 인증 기관(CA)에서 발급한 인증서를 제공하고, 브라우저는 이를 확인합니다.
  3. 키 교환: 안전한 통신을 위한 대칭 키를 교환합니다.
  4. 암호화된 통신: 이후 모든 데이터는 앞서 합의한 키를 사용해 암호화되어 전송됩니다.

 

결론

HTTP와 HTTPS는 웹 페이지를 보기 위한 통신 규약입니다. HTTP는 단순하고 기본적인 통신 방법이지만 보안에 취약하고, HTTPS는 암호화와 인증을 통해 안전한 통신을 제공합니다. 현대 웹에서는 사용자 정보 보호와 신뢰성 확보를 위해 점점 더 많은 웹사이트가 HTTPS를 채택하고 있습니다.

여러분이 웹 주소창에서 http:// 또는 https://를 볼 때, 이제는 그것이 단순한 글자가 아니라 여러분의 데이터가 어떻게 전송되는지를 나타내는 중요한 정보임을 알 수 있을 것입니다.

728x90
저작자표시

'1일 1네트워크 > 제 6장: 애플리케이션 계층 프로토콜' 카테고리의 다른 글

MIME와 MIME타입이란?  (0) 2025.04.04
IMAP이란?  (0) 2025.04.03
POP란?  (0) 2025.03.28
SMTP란?  (1) 2025.03.27
FTP란?  (0) 2025.03.26

1. HTTP vs HTTPS

웹 통신의 기본 프로토콜인 HTTP(Hypertext Transfer Protocol)는 클라이언트와 서버 간의 데이터 교환을 위한 기본적인 규칙을 제공합니다. 그러나 HTTP는 보안 측면에서 몇 가지 중요한 취약점을 가지고 있습니다. 이러한 취약점을 해결하기 위해 개발된 것이 바로 HTTPS(HTTP Secure)입니다.

HTTPS는 기존 HTTP 프로토콜에 보안 계층을 추가한 것으로, 주로 SSL(Secure Sockets Layer) 또는 그 후속 버전인 TLS(Transport Layer Security)를 사용합니다. 이를 통해 데이터의 기밀성, 완전성, 그리고 통신 상대방 인증 측면에서 큰 개선을 이루었습니다.

2. HTTP의 보안 취약점

HTTP가 가진 주요 보안 취약점은 다음과 같습니다:

a) 암호화 기능 부재:
   HTTP는 데이터를 평문으로 전송합니다. 이는 누구나 네트워크 트래픽을 감시하면 통신 내용을 쉽게 볼 수 있다는 것을 의미합니다. 예를 들어, 공공 Wi-Fi에서 HTTP를 사용하면 비밀번호나 신용카드 정보 같은 민감한 데이터가 노출될 위험이 있습니다.

b) 메시지 변경 감지 불가
   HTTP는 전송 중 데이터가 변경되었는지 확인할 방법이 없습니다. 즉, 중간자 공격(man-in-the-middle attack)에 취약합니다. 악의적인 제3자가 통신을 가로채 내용을 변경해도 수신자는 이를 알아차리기 어렵습니다.

c) 통신 상대 인증 불가
   HTTP는 통신 상대방이 진짜 의도한 서버나 클라이언트인지 확인할 수 없습니다. 이는 피싱 사이트 같은 위장 서버나 악의적인 클라이언트의 요청을 구분하기 어렵다는 것을 의미합니다.

3. HTTPS의 구조
HTTPS는 이러한 HTTP의 취약점을 해결하기 위해 HTTP와 TCP 사이에 보안 계층을 추가합니다. 이 보안 계층은 SSL/TLS 프로토콜을 사용합니다.

SSL과 TLS는 본질적으로 같은 프로토콜의 다른 버전입니다. TLS가 SSL의 더 최신 버전이지만,

일반적으로 'SSL'이라는 용어가 더 널리 사용됩니다. 이 프로토콜은 다음과 같은 보안 기능을 제공합니다
- 데이터 암호화
- 데이터 무결성 검증
- 서버 (그리고 선택적으로 클라이언트) 인증

4. 암호화 방식: 대칭키와 비대칭키
HTTPS는 두 가지 주요 암호화 방식을 사용합니다:


a) 대칭키 암호화:
   - 동일한 키를 사용하여 암호화와 복호화를 수행합니다.
   - 장점: 암호화와 복호화 속도가 빠릅니다.
   - 단점: 키를 안전하게 공유하는 것이 어렵습니다. 처음에 키를 전달할 때 탈취 당하면 모든 통신이 위험해집니다.

b) 비대칭키 암호화 (공개키 암호화)
   - 두 개의 다른 키(공개키와 개인키)를 사용합니다.
   - 공개키로 암호화한 데이터는 개인키로만 복호화할 수 있습니다.
   - 장점: 키 교환의 안전성이 높습니다.
   - 단점: 대칭키 방식에 비해 암호화/복호화 속도가 느립니다.

HTTPS는 이 두 방식의 장점을 활용하기 위해 하이브리드 방식을 사용합니다
1. 처음에 비대칭키 암호화를 사용하여 안전하게 대칭키를 교환합니다.
2. 이후 실제 데이터 통신은 빠른 대칭키 암호화를 사용합니다.

5. 인증서와 CA(Certificate Authority)
HTTPS에서 중요한 또 다른 요소는 디지털 인증서입니다. 인증서는 서버의 신원을 보증하는 역할을 합니다. 이 인증서는 신뢰할 수 있는 제3자 기관인 CA(Certificate Authority)에서 발급합니다.

CA의 역할:
- 서버의 신원을 확인합니다.
- 서버의 공개키를 포함한 인증서를 발급합니다.
- 인증서에 디지털 서명을 추가하여 인증서의 진위를 보증합니다.

클라이언트(예: 웹 브라우저)는 서버가 제시한 인증서를 CA의 공개키를 사용하여 검증합니다. 이를 통해 서버의 신원과 공개키의 신뢰성을 확인할 수 있습니다.

6. HTTPS 통신의 흐름
HTTPS 통신은 다음과 같은 단계로 이루어집니다
1) 클라이언트가 서버에 연결을 요청합니다.
2) 서버는 자신의 SSL 인증서를 클라이언트에게 전송합니다.
3) 클라이언트는 받은 인증서를 확인합니다:
   - 인증서가 신뢰할 수 있는 CA에 의해 발급되었는지 확인
   - 인증서가 유효한지 (만료되지 않았는지) 확인
   - 인증서의 도메인 이름이 접속하려는 웹사이트와 일치하는지 확인
4) 인증서가 유효하다고 판단되면, 클라이언트는 대칭키(세션 키)를 생성합니다.
5) 클라이언트는 이 세션 키를 서버의 공개키로 암호화하여 서버에 전송합니다.
6) 서버는 자신의 개인키를 사용하여 암호화된 세션 키를 복호화합니다.
7) 이제 클라이언트와 서버는 동일한 세션 키를 공유하게 되었고, 이를 사용하여 안전한 대칭키 암호화 통신을 시작합니다.

7. 결론
HTTPS는 SSL/TLS를 통해 HTTP의 보안 취약점을 효과적으로 보완합니다. 대칭키와 비대칭키 암호화의 장점을 결합하고, CA의 인증 시스템을 활용하여 안전한 통신 환경을 제공합니다. 이를 통해 데이터의 기밀성(암호화), 무결성(변조 방지), 그리고 통신 상대방의 신원(인증)을 보장할 수 있습니다.

HTTPS의 사용은 온라인 뱅킹, 전자상거래, 개인정보 처리 등 민감한 정보를 다루는 웹사이트에서 특히 중요하며, 현대 웹의 필수적인 요소로 자리잡았습니다. 사용자의 개인정보 보호와 안전한 온라인 경험을 위해 HTTPS의 중요성은 계속해서 증가하고 있습니다.

728x90
저작자표시

'코딩공부 > 개발지식' 카테고리의 다른 글

단위 테스트의 품질을 높이는 방법: AAA 패턴과 안티 패턴 분석  (1) 2024.07.22
의존성 주입(Dependency Injection)의 개념과 장단점  (0) 2024.07.22
개발자의 악몽, 데드락(Deadlock)  (0) 2024.07.18
디자인 패턴: 반복적인 문제상황에서 재사용 가능한 해결책  (0) 2024.07.18
SOLID 원칙: 객체 지향 프로그래밍의 다섯 가지 핵심 원칙  (0) 2024.07.18

  1. URL 파싱 및 HTTP 요청 생성: 브라우저가 URL을 해석하여 HTTP 요청 메시지를 생성하고, 이를 운영체제에 전송 요청합니다.
  2. DNS 룩업: 도메인 이름을 IP 주소로 변환하기 위해 DNS 룩업을 수행합니다. 크롬 같은 브라우저는 먼저 로컬의 hosts 파일과 DNS 캐시를 확인합니다.
  3. 프로토콜 스택을 통한 패킷 처리: 운영체제 내의 프로토콜 스택이 HTTP 요청을 네트워크 패킷으로 변환하고 제어 정보를 추가합니다.
  4. LAN 어댑터를 통한 전송: LAN 어댑터가 패킷을 전기 신호로 변환하여 네트워크로 송출합니다.
  5. 인터넷 접속 경로를 통한 이동: 패킷은 스위칭 허브를 거쳐 ISP를 통해 인터넷으로 전송됩니다.
  6. 인터넷의 핵심부를 통한 전달: 패킷은 여러 고속 라우터를 거쳐 인터넷의 핵심부를 통과하여 목적지로 이동합니다.
  7. 목적지 LAN 도착 및 검사: 패킷은 목적지의 LAN에 도착하며, 방화벽에서 검사 후 필요한 경우 캐시 서버로 이동합니다.
  8. 웹 서버에서의 처리: 웹 서버는 프로토콜 스택을 통해 패킷을 추출, 메시지를 복원하고, 웹 서버 애플리케이션으로 전달합니다.
  9. 응답 데이터 작성 및 회송: 웹 서버 애플리케이션은 요청에 대한 응답 데이터를 작성하여 클라이언트로 다시 보냅니다. 이 응답도 동일한 경로를 통해 전송됩니다.
728x90
저작자표시

'Computer Science (CS)' 카테고리의 다른 글

[CS공부 - 7회] 트랜잭션의 개념과 격리 수준  (0) 2023.11.03
[CS공부 - 6회] 멀티 프로세스와 멀티 스레드  (1) 2023.11.02
[CS공부 - 5회] RESTful API  (0) 2023.10.31
[CS공부 - 4회] 동기와 비동기 (블로킹과 논블로킹)  (0) 2023.10.27
[CS공부 - 3회] 객체지향과 절차지향 프로그래밍  (1) 2023.10.25

+ Recent posts

티스토리툴바