CS공부 - 네트워크

네트워크 개요

• 네트워크 : 컴퓨터간의 통신(파일,이메일,웹문서 송수신)을 일컫으며 이 통신에는 합의된 규칙(프로토콜)이 있음
• 프로토콜 : 컴퓨터간 통신을 하기위한 규칙. 결국에는 0과 1의 전달이지만 0과 1의 배치에는 통신이 가능하도록 하는 룰이 있음. 예를들어 숫자의 나열 중에 몇번째 자리는 메타데이터이며 몇번째 자리이후는 실제 데이터다 등의 규칙이 존재함.
  • 택배박스의 택배송장(목적지, 내용물, 분류 등등의 정보)와 유사한 역할을 하며, 한번에 end to end 통신이 아니기고 중개하는 장치들이 많이 관여하기때문에 그게 걸맞게 여러가지 프로토콜이 존재함

물리적 범위에 따른 네트워크 구분

• 물리적 커버 범위에 따라서 지역의  LAN(Local Area Network), 무선의 WLAN(Wireless), ISP(인터넷서비스 프로바이더)가 제공하는 광역의 WAN(Wide)이 존재함. 해당 부분의 자세한 내용은 네트워크를 전문으로하는 네트워크 엔지니어의 영역이며 프로그래밍과는 다소 괴리가 있음.
• LAN(Local Area Network) : 각각의 Device에 부착된 LAN 카드로 통신, 해당 지역의 네트워크를 모두 연결하고 중개하는 허브에 연결하기 위해 사용. WLAN(Wireless Local Area Network)도 존재한다.
• WAN(Wide Area Network) : 인터넷서비스제공자(ISP ; SK,KT)이 제공하는 광역 네트워크. 지역의 중개허브들을 연결하여 국가 내, 국가 간 케이블을 통해서 데이터를 송수신한다. ISP 외에도 Google같은 사기업이 국가 간 케이블을 보유하는 경우도 있음.
• 인터넷이란 이중에서도 전세계를 연결하는 공용의 통합망인 특정한 네트워크 시스템을 지칭하는 것

OSI 7 계층

• ISO(국제표준화기구)에서 컴퓨터간 통신체계와 프로토콜에 대해서 표준화 스펙을 제시한 개념 실제와 완전히 동일하지는 않으나 개념화라는 측면에서 유용
• OSI 7계층의 핵심은 캡슐화를 통한 계층화와 이에 따른 계층 간 독립성에 있다.
  • Encapsulation : 각 전송의 계층마다 역할에 필요한 정보가 있고 그 필요한 정보를 data 앞의 head부문에 부착을 하는 형태이다. 계층별로 header의 capsulation과 decapsulation을 통해 전송을 위한 정보를 교환하고 이에 따라 전송의 행위를 한다. 
  • 이때, 이전 계층의 head는 다음 계층에서 통으로 data로 취급하여 계층 간 독립성을 유지한다. 이러한 계층별 독립적 전송방식은, 한 계층의 프로토콜 변화로 인해서 다른 계층도 종속적으로 변경해야하는 경우를 방지한다.

OSI 7 계층별 역할

암기법 : A아P파S서T탈N났D다PHY픽

• 1계층 (물리계층Physical ) : 시스템간 물리적 연결과 전기신호 변환  및 제어
  • 0과1의 데이터를 전기파동으로 변환, 역으로도 변환
• 2계층 (데이터링크 계층 Datalink) : 기기 간 end to end 데이터 전송 및 물리주소 결정
  • 이더넷 프로토콜로 랜카드에서 랜카드로 데이터 전송
  • 랜카드마다 고유한 맥주소를 사용, 전송시 Source Mac Address, Destination Mac Address 둘다 보냄.
  • 데이터링크 계층까지의 데이터를 프레임, 네트워크 계층부터의 데이터를 패킷이라 칭함.
• 3계층 (네트워크 계층 Network) : 다른 네트워크와 통신을 위한 경로 설정 및 논리주소 결정
  • 광역  WAN 네트워크 내에서의 IP 프로토콜을 활용하여 국가 간, 국가 내 최적의 경로를 Routing 관리.
  • The data is divided into packets. 
• 4계층 (전송계층 Transport ) : 기기간 데이터가 신뢰할 수 있도록 통신을 구현함
  • 1. 데이터 신뢰성 ; 체크섬 : 데이터가 전송중 유실이 있는지 확인, 데이터가 유실되면 재전송 등의 조취를 취함
  • 2. 데이터 프로그램 목적지 ; 포트 : 데이터를 어떤 응용프로그램에 전달되어야하는지 구분함. 전송시 Source Port, Destination Port 둘다 포함.
  • 프로그램별로 일반적으로 많이쓰는 포트번호가 있음 (웹서버 80번 이메일 110번 FTP 21번) 
• 5계층 (세션계층Session) : 세션체결 , 통신방식 등을 결정
  • 동시에 여러 종류의 데이터(여러개의 파일)을 받을때 논리적으로 구분하고 병렬적으로 다운받을 수 있도록 하는 것
  • Primary Role: Managing and controlling the dialog between two applications.
• 6계층 (표현계층 Presentation) : 문자코드, 압축, 암호화 등의 데이터 변환 담당; 
• 7계층 (응용계층 Application) : 이메일, 파일전송, 웹사이트 열람 등 응용프로그램이 필요로하는 데이터를 제공하는 프로토콜;
  • 어플리케이션 별로 필요한 데이터를 제공, application-specific protocols such as HTTP, FTP, SMTP, etc.,

OSI7은 개념적인 스펙이며 실제로 사용되는 것은 TCP/IP 스택이다.

 

방화벽

방화벽은 OSI 계층에서 3계층(네트워크), 4계층(전송), **7계층(응용)**에서 주로 동작하며, 계층마다 차단과 허용의 기준이 다릅니다.

 

1. OSI 3계층(네트워크 계층) 방화벽 : IP 주소를 기반으로 접근 제어.

• 사례: AWS Security Group에서 특정 IP 대역(203.0.113.0/24)만 SSH(22번 포트) 허용.

2. OSI 4계층(전송 계층) 방화벽 : TCP/UDP 포트 기반으로 접근 제어:

• 애플리케이션이 사용하는 포트(예: 80, 443, 3306)를 기준으로 허용/차단. 연결 상태를 추적하고, 합법적인 연결만 유지(상태 기반 방화벽).
• 포트 관리 : 불필요한 포트는 닫아 보안을 강화.
  • 애플리케이션 서버: HTTP(80), HTTPS(443)만 열고 다른 포트 차단.
  • 데이터베이스 서버: 외부에서 접근 가능한 포트를 닫고, 내부 IP를 통해서만 접근 허용.
    • ufw allow 3306 from 10.0.0.0/24

3. OSI 7계층(응용 계층) 방화벽

• 애플리케이션 데이터와 프로토콜 기반으로 트래픽 제어:

• • HTTP, FTP, SMTP 같은 프로토콜을 분석.SQL Injection, XSS, 악성 파일 업로드 방어.
  • 사례 : WAF(Web Application Firewall) 사용 ; 특정 URL 패턴(/admin/*)에 대한 비인가 요청 차단, 악성 HTTP 요청 차단(예: 너무 큰 요청 크기, 비정상적인 요청 헤더).
    • AWS WAF에서 특정 IP 또는 User-Agent를 기반으로 요청 차단.
•  

IP 프로토콜( 네트워크계층)

• IP : InternetProtocol로 version4의 경우 0.0.0.0 ~256.256.256.256까지 8비트 4개의 32비트로 구성되어있음.
  • 자기 PC의 IP주소는 127.0.0.1임
  • 도메인 name으로 DNS서버를 통해서 웹서버의 IP주소도 확인가능함 (CLI ping daum.net으로 확인가능)
• IPv6 : 현재 모바일,PC,태블릿 등 다수의 인터넷 기기 보급으로 인해 IPv4의 IP개수 부족으로 16비트 8개의 128비트로 구성된 IPv6가 도입됨
• 그러나, IPv4가 보급된 현상황으부터 IPv6로 변경이 어려움. 때문에, 지역허브단위로 국제 IP주소를 부여하고 지역허브 내의 기기에는 local에서 정의되고 내부적으로만 유효한 Private IP주소를 구분하여 대응하고 있음.
• IP주소 표기법
  
  • IP 주소는 두 부분으로 나뉨
  • 네트워크 부분: 네트워크 식별 (서로 같은 네트워크인지 결정)
  • 호스트 부분: 같은 네트워크 내에서 개별 장치를 구분
  • 같은 네트워크인지 확인하는 가장 기본적인 방법은 서브넷 마스크를 확인하는 것입니다.서브넷 마스크가 같다면, IP 주소의 네트워크 부분이 일치하는 경우 같은 내부 네트워크에 속합니다.
  • 서브넷 마스크(255.255.255.0)에서 1이 있는 부분은 네트워크, 0이 있는 부분은 호스트. 서브넷 마스크의 크기에 따라 같은 네트워크에 포함될 수 있는 IP 주소의 범위가 달라집니다.

 

TCP/ UDP 프로토콜(전송계층)

• -TCP : 연결형 프로토콜(3way& 4way Handshake) 데이터의 전송순서 및 신뢰성 보장
  • HTTP 통신 개시 이전에 TCP 핸드쉐이크가 선행되어야하고 핸드쉐이크 과정에서는 HTTP 데이터는 포함되지 않음.
• -UDP : 비연결형 프로토콜, TCP보다 빠른 전송속도, 스트리밍/브로드케스팅에 주로 사용
• Port : TCP는 포트 번호를 사용하여 하나의 IP주소에서 여러개의 특정 애플리케이션 또는 서비스를 식별하여 통신할 수 있도록 구분해줍니다. 하지만 TCP는 데이터의 내용이나 형식을 정의하지 않습니다. 즉, 어떤 데이터를 보낼지, 어떻게 해석할지는 애플리케이션 계층에서 결정합니다.
  
  • 포트 번호는 0부터 65535까지 있으며, 잘 알려진 포트(Well-Known Ports)는 0~1023 사이입니다.
    
•  

 

HTTP 프로토콜(응용계층)

Http도 결국에는 프로토콜의 종류중 하나. 인터넷 상에서 정보를 주고받는 프로토콜이며 Http로 통신하는 '웹서버'라는 어플리케이션에서 해독할 수 있는 프로토콜이다.

• 웹 서버 (Web Server) : HTTP 요청을 받아 정적 콘텐츠(HTML, CSS, JavaScript, 이미지 등)를 클라이언트(브라우저)에 응답.
• 웹 애플리케이션 서버 (Web Application Server, WAS) : 웹 서버로부터 전달받은 HTTP 요청을 바탕으로 동적 콘텐츠를 생성. 데이터베이스와 상호작용하거나, 비즈니스 로직을 처리한 후 HTTP 응답을 생성.
• 웹의 특성: HTTP프로토콜의 컨텐츠는 HyperText라는 개념을 기반으로, 다른 문서나 리소스를 연결하는 것입니다. 이것이 웹의 가장 기본적인 구조와 작동 방식을 만들어내며, 웹 브라우징의 본질이 됩니다.
  • 하나는 서버의 응답(Response)**에 **또 다른 요청(Request)으로 이어지는 내용(하이퍼링크, 리소스 경로 등)**이 포함된다
  • 웹 브라우저에서 하이퍼링크를 클릭 → HTTP 요청 생성 → 서버에서 해당 리소스 응답 → 새 문서로 이동.

• Http의 특성 : Server/Client 모델을 가정하여 Request/Response로 통신함; 프로토콜의 형식에 따라서 Client가 요청을 보내면 Server에서 응답
• Http의 특성2 : Connectionless(Stateless)특성;  HTTP는 한 프로토콜로 1회성 response와 request를 전제로 하기에 이전의 통신내용이 후속의 통신내용에 영향을 미치지않는다. 그러므로 로그인을 한 행위가 후속 통신에 저장되지 않기에 추가적으로 다른 기능으로 보완함.
  • HTTP1.1 개선점 : Connectionless를 보완하기 위해서 HTTP1.1부터 Keep Alive기능을 지원해서, 설정된 timeout시간까지는 TCP HandShake 재연결 과정없이 (IP는 네트워크 Layer에서 많이 쓰고 HTTP는 TCP를 주로 사용) 데이터 송수신이 가능해졌다. 따라서 HTTP N회 송수신을 위해서 TCP Handshake 과정을 N번 반복할 필요가 없어졌다.
• Http의 특성3 : 확장성 ; HTTP는 다양한 데이터 형식을 지원하며, 확장 가능한 구조를 가지고 있습니다.
  • 컨텐츠 타입(Content-Type): HTML, JSON, XML, 이미지, 동영상 등 다양한 데이터 형식 전송 가능.
  • 헤더 필드(Header Fields): : 표준 헤더 외에도 사용자 정의(Custom Header)를 추가하여 유연한 통신 가능.

 

HTTP Method

• Get Method : 정보읽어들이기 (Select)
  
  • 데이터가 URL 뒤에 Query Parameters 혹은 Path Variables 형태로 전송됩니다.
  • URI(Uniform Resource Identifier) : 통합자원식별자, URL은 URI의 하위개념으로 URL은 웹에서 자원을 찾을때만 지칭함
    • URL- Path Variables: 특정한 하나의 유니크한 자원을 식별하기 위해 사용. 파라미터와 값을 /로 구분하여 파라미터들이 명시적으로 보이지 않음. (: /users/123) 
    • URL - Query Parameters: collection중에 필터링을 걸어서 조건에 충족하는 데이터를 찾기 위해서 사용. 끝에 물음표를 사용하여 parameter와 값을 구분하여 파라미터들이 명시적으로 보임 (/users?page=1&size=20). 
      • Get방식에서는 HTTP body를 사용하지않고 url을 통해서 parameter을 전달함. 이차이는
        • 1. restul서비스는 stateless하고 이 특성에 맞추어 get하고자하는 자원이 독특하다면 자원의 주소인 url 역시 독특해야한다. 
        • 2. 전달하고자하는 데이터가 비교적 단순하기에
• Post Method(Insert) : 데이터를 새로 생성할때 사용하거나 GET방식으로 URL에 넣기 민감한 정보를 Body에 숨길때 사용
  • 전달이 필요한 파라미터들을 HTTP body에 포함되어 사용자는 URL을 통해서 직접확인 불가능
• PUT Method (UPDATE) : 서버에 이미 존재하는 리소스를 전체 업데이트할 때 사용됩니다. 전송된 모든 필드를 업데이트하여 기존 데이터를 완전히 대체합니다.
• DELETE Method (DELETE) : 서버에 있는 특정 리소스를 삭제할 때 사용됩니다
• PATCH Method (Partial Update) : 리소스의 일부 필드만 업데이트할 때 사용됩니다. 전체 리소스를 대체하는 PUT과 달리, 특정 필드만 수정할 수 있습니다.

REST API

• REST (Representational State Transfer) : '자원의 표현에 의한 상태전달'이라는 설계원칙. 개발자들 사이에서 웹서버 구현가이드.
  • Represntational State : Representation of data란 db의 data를 직접적으로 송수신하는 것이 아니라 json과 같은 특정한 포맷으로 담아서 전송한다는 의미로, client-server가 db에 종속적이지 않은 관계를 갖는다는 의미.
  • Resource-Based:  각각의 자원들은 각각의 HTTP URL을 통해 unique하게 명시되어 각 자원끼리 혼동이 없도록 명확화.
  • Standard HTTP Methods:  http method를 CRUD(create - post, read - get, update - put, delete - delete) Operation 의 의미에 부합하도록 사용
    • http method와 url은 모드 string parsine으로 식별하고, 웹서버에서 해당 method와 url에 특정 메소드를 맵핑하는 방식이기때문에, http method와 의미적으로 부합하지않는 로직을 구현할 수 있기에 이를 막고자 rest원칙을 권장
• RESTful API : Rest 설계원칙을 충실히 따르는 API를 말한다. REST기반으로 마이크로 서비스나 OPEN API를 구현한 것.
  •  마이크로 서비스란 하나의 서비스를 생성하기 위해서 각 세부 기능을 데이터별로 서버를 분산하여 대용량의 요청을 빠르게 처리하며 서로 독립성을 유지하는 하도록 API로 분리한것.

Restful API 설계 예시

 

HTTP 프로토콜 구조

• HTTP통신의 내용은 ASC코드로 표현하도록 되어있어서 String형태이다. 그리고 줄바꿈으로 내용을 구분한다.
  • 첫번째 줄
    • request일시 HTTP method, URL(웹서버에서 보관하고 있는 resource의 가상적인 주소)
    • response일시 HTTP 버전, 요청의 상태코드, 상태코드에 해당하는 메세지
      • {status code : 1xx Informational, 2xx Success, 3xx Redirection, 4xx Client Errors, 5xx Server Errors}
  • 두번째줄~ 줄바꿈 이전 : header(해당 http에 대한 메타데이터)
  • 줄바꿈후 : requestbody(본문)

 

 

 

쿠키와 세션

 

HTTP는 Statless로 통신이 끝나면 이전 작업을 기억하지 않음. 이를 극복하기 위한 것이 쿠키와 세션임

• Cookie기반방법
  • HTTP Header 내에는 Connection(Keep-Alive), User-Agent(기기정보 및 브라우저 정보) 같은 정보 외에도 Cookie라는 정보가 있음. 쿠키는 두 요청이 동일한 클라이언트에서 들어왔는지 아닌지를 판단할 때 주로 사용함. (Stateless극복)
  • 가령 사용자가 최초 로그인을 통해서 인증을 할때, 서버는 쿠키에 로그인 관련된 정보를 저장하도록 Set-Cookie 명령을 내릴 수 있음. 그러나 이방식은 쿠키에 로그인 관련정보를 직접적으로 저장하기 때문에, 보안에 취약함.
  •  
• Session기반방법
  • Session은 Client가 로그인시에 상태를 Session이라는 객체로 서버에 저장하여 보관함. 그리고 Cookie에 로그인 관련 정보가 아니라  Session의 식별자를  클라이언트를 부여하고 이를 매 Reqeust의 Cookie에 저장하고 서버는 DB 내 세션 정보를 확인하여 사용자 인증을함.
    • HTTP 통신이 노출된다고해도 ID,PW같은 로그인 정보가 유출되는 것을 막을 수 있음.
    • Session ID를 탈취하여 사용하는 경우에도 보안성이 유지가능한데, 이는 유저의 IP, ID, User-Agent 등 유저의 특성에 맞는 것들을 모두 총합하여 만들 Key값이기때문에 이것이 완전히 동일하지 않으면 SessionID가 동일하지 않으므로 SessionID 검증작업에서 걸림.'
• 유효기간
  • Expires설정(유효기간) : Cookie 정보는 서버에서 저장한 기간까지만 유효하고 그 이후에는 삭제됨. 설정이 없다면 브라우저 종료시에 삭제됨.

REST API

• REST (Representational State Transfer) : '자원의 표현에 의한 상태전달'이라는 설계원칙. 개발자들 사이에서 웹서버 구현가이드.
  • Represntational State : Representation of data란 db의 data를 직접적으로 송수신하는 것이 아니라 json과 같은 특정한 포맷으로 담아서 전송한다는 의미로, client-server가 db에 종속적이지 않은 관계를 갖는다는 의미.
  • Resource-Based:  각각의 자원들은 각각의 HTTP URL을 통해 unique하게 명시되어 각 자원끼리 혼동이 없도록 명확화.
  • Standard HTTP Methods:  http method를 CRUD(create - post, read - get, update - put, delete - delete) Operation 의 의미에 부합하도록 사용
    • http method와 url은 모드 string parsine으로 식별하고, 웹서버에서 해당 method와 url에 특정 메소드를 맵핑하는 방식이기때문에, http method와 의미적으로 부합하지않는 로직을 구현할 수 있기에 이를 막고자 rest원칙을 권장
• RESTful API : Rest 설계원칙을 충실히 따르는 API를 말한다. REST기반으로 마이크로 서비스나 OPEN API를 구현한 것.
  •  마이크로 서비스란 하나의 서비스를 생성하기 위해서 각 세부 기능을 데이터별로 서버를 분산하여 대용량의 요청을 빠르게 처리하며 서로 독립성을 유지하는 하도록 API로 분리한것.

Restful API 설계 예시

 

 

HTTPS (HyperText Transfer Protocol Over Secure Socket Layer)

• HTTP는 모든 컨텐츠 내용이 ASC코드로 오픈되어 있음.
• HTTP는 80포트를 사용하지만, HTTPS 기본포트는 443
• HTTPS는 HTTP 통신시 사용하는 TCP 위에  TLS(Transport Layer Security)/ SSL(Secure Sockets Layer) 계층을 추가하여 일반 텍스트 송수신 대신 데이터 암호화하여 송수신 
  
  • TCP → TLS → HTTP (HTTPS)
  • TCP → HTTP (HTTP)

 

 

DNS 프로토콜(Domain Name System, 응용프로토콜)

• IP를 확인해야 서버를 향해서 라우팅이 가능하기 때문에, 도메인 이름을 IP로 혹은 그 반대를 수행하기 위한 프로토콜
• Transfer Layer은 TCP를 사용하지않고 UDP를 사용한다.

 

메일서버의 프로토콜 ( 응용 프로토콜)

메일 송신과 수신은 각각 다른 프로토콜을 사용한다. 

 

SMTP 프로토콜 (Simple Mail Transfer Protocol) 

• Client의 메일 송신 및 서버 간의 메일 송수신을 위한 프로토콜로 단방향(발신자 → 수신자 서버)통신이다.
  • 포트번호는 25번 혹은 587번을 사용한다.
• SMTP 프로토콜은 오래전 개발된 표준으로 텍스트(ASCII코드)만 전송가능, 때문에 한국어,멀티미디어 같은 non-ASCII코드는 SMTP 바디에 MIME(Multi-purpose Internet Mail Extension)프로토콜로 인코딩하여 발송한다.

IMAP(Internet Message Access Protocol)

• Client와 서버간의 메일 송수신을 위한 프로토콜
  • 143번 포트를 사용
• 중앙서버에서 메일 동기화하여 모든 장치에서 동일한 이메일 폴더 확인가능
  • 서버가 클라이언트에 메일 컨텐츠를 발송할 뿐아니라 클라이언트가 서버로 메일 상태(읽음, 삭제, 정리 등)를 통신하여 양방향 통신
  • 대표적인 서비스로 Gmail이 여기에 해당한다고 할 수 있음
  • 서버의 통신과 저장자원을 사용하여 어디서나 일관된 메일 

 

POP3 프로토콜 (Post Office Protocol)

• Client와 서버간의 메일 송수신을 위한 프로토콜
  
  • 후자는 110번 포트를 사용
• 중앙 서버에서 로컬 장치로 이메일을 내려받음, 내려받은 이메일은 중앙서버에서 지우는 것이 디폴트 동작
  
  • 서버 → 클라이언트로 메일을 다운로드시켜, 단방향으로 통신하여 동기화되지 않음.
  • 대표적인 서비스로 Outlook이 여기에 해당한다고 할 수 있음
•  서버의 통신과 저장자원을 아끼고 싶을때 사용
  • 3번 메일을 서버에서 발송하지 않고 삭제 하는 등 로컬의 상태와 서버 상태가 다른 동기화 문제가 발생할 수 있음. 

 

통신 프로토콜에 따른 개별서버존재

메일 서버가 HTTP 기반의 웹 통신과는 다른 통신 방식을 사용하기 때문에 별도로 존재하는 것이며, 이러한 통신 방식 차이로 인해 별도 서버가 필요한 경우는 다른 시스템에서도 흔히 발생합니다.

 

(1) 파일 전송 서버 : FTP 서버: 파일 전송 프로토콜(FTP)을 사용하는 서버로, 파일 업로드/다운로드를 처리.

(2) 데이터베이스 서버 : SQL 통신: 애플리케이션 서버(WAS)와 데이터베이스 서버(DBMS)는 SQL 프로토콜을 통해 통신.

(3) 메시지 브로커 : RabbitMQ, Kafka 등: HTTP 대신 AMQP, MQTT, gRPC 같은 메시지 전송 프로토콜을 사용.

(4) DNS 서버 : 도메인 이름을 IP 주소로 변환하기 위해 별도의 DNS 서버가 필요.

(6) 스트리밍 서버 : RTSP, WebRTC: : 실시간 동영상/오디오 스트리밍은 HTTP보다 효율적인 RTSP나 WebRTC 같은 프로토콜을 사용

(7) IoT 디바이스 서버 : IoT 장비는 HTTP 대신 CoAP, MQTT 같은 경량 프로토콜을 사용.

(8) 게임 서버 : 게임 서버는 HTTP 대신 TCP/UDP 기반 프로토콜을 사용.

(9) 메일서버 : 메일서버는 HTTP 대신 SMTP, POP3, IMAP기반 프로토콜 사용

 

웹 브라우저의 전체 동작과정 정리

1. 웹브라우저에 입력된 String URL은 DNS프로토콜을 사용해 IP주소로 변환된다

2. HTTP request는 운영체제의 네트워크 스택에 따라서 HTTP - TCP - IP - Ethernet을 전기신호로 변환, 전송한다

3. 웹브라우저 내에서의 동작  - DOM : Document Object Model과 Virtual DOM;

3.1 웹브라우저는 tag로 이루어진 html 파일을 파싱하여  hierarchy를 갖는 Dom Tree를 생성한다.

3.2 CSS정보를 파싱하여 CSSOM tree를 생성하고 두가지 트리를 기반으로 Render Tree를 생성한다. 

3.3 Render Tree를 토대로 최종적으로 rendering을 한다.

3.4 js는 html과 css를 동적으로 변화시키는데, 그럴 경우 Dom tree변경 ~ Rendering과정을 javascript 동작만큼 계속해서 반복하여 Overhead를 발생시킨다. 이를 개선하기 위해서 Dom의 변경사항을 json형태로 임시저장해놓고(Virtual Dom) javascript가 더이상 동작하지 않을때 그때까지의 모든 변경사항을 한번에 DOM tree에 적용시켜 한번만 Rendering과정을 거친다. 

- react나 vue.js에서 이를 활용함

 

1. URL 입력 및 DNS 요청
   사용자가 브라우저에 URL을 입력하면, 브라우저는 DNS 서버에 요청을 보내 해당 URL의 도메인 이름에 대응하는 IP 주소를 조회합니다.
2. 서버 연결 및 HTTP 요청 전송
   조회된 IP 주소를 기반으로 브라우저가 해당 서버와 TCP 연결(3-way handshake)을 설정하고, 웹 페이지 데이터를 요청하는 HTTP(S) 요청을 전송합니다.
3. 서버 처리 및 응답 생성
   서버는 요청받은 내용을 처리하고, HTML, CSS, JavaScript 파일 등의 응답 데이터를 생성하여 브라우저에 전달합니다.
4. 브라우저 렌더링
   브라우저는 서버에서 받은 데이터를 해석해 웹 페이지를 화면에 렌더링합니다. 이 과정에서 HTML 구조를 파싱하고, CSS를 적용하며, JavaScript를 실행합니다.
5. 추가 요청 및 상호작용
   필요에 따라 브라우저는 외부 리소스(CDN 이미지, 동영상 등)를 추가로 요청하고, JavaScript가 사용자와의 상호작용을 처리하여 동적인 콘텐츠를 제공합니다.

클라이언트 처리

1. 응용 계층 (HTTP 프로토콜): 클라이언트가 HTTP 요청 메시지 작성됩니다.
2. 표현 계층: 요청 데이터를 암호화(TLS/SSL 사용 시).콘텐츠 인코딩(예: Gzip 압축)이 적용될 수 있음.
3. 세션 계층: 서버와 세션 연결 설정. HTTPS라면 TLS 핸드셰이크로 암호화 세션 생성.
4. 전송 계층 (TCP): 데이터를 작은 세그먼트로 분할. TCP는 포트 번호(예: 443번 포트)를 사용해 클라이언트와 서버 간 통신 경로 설정.
5. 네트워크 계층 (IP): 데이터를 IP 패킷에 캡슐화. 클라이언트와 서버의 IP 주소를 기반으로 라우팅.
6. 데이터 링크 계층: IP 패킷을 데이터 프레임으로 변환. 로컬 네트워크에서 MAC 주소를 기반으로 전달.
7. 물리 계층: 데이터를 전기 신호 또는 광 신호로 변환해 전송. 네트워크 케이블, 무선 신호를 통해 데이터가 이동.

서버 측 처리

• 서버는 물리 계층에서 받은 신호를 데이터 링크 계층으로 전환.
• 데이터 링크 계층은 프레임을 분석해 네트워크 계층으로 전달.
• 네트워크 계층은 IP 주소를 확인해 패킷을 전송 계층으로 전달.
• 전송 계층(TCP)은 패킷을 조립해 세션 계층으로 전달.
• 세션 계층은 요청 세션을 확인하고 데이터를 표현 계층으로 전달.
• 표현 계층은 암호화를 복호화하거나 압축을 해제.
• 응용 계층(HTTP 서버)은 요청을 처리하고 응답 메시지를 생성: