HTTP와 네트워크

HTTP-WEB

Web : HTML이라는 문서 형태와 HTTP라는 문서 전송 프로토콜, URL로 문서의 위치를 표시하는 시스템

HTTP (Hypertext Transfer Protocol)

• 웹에서 데이터를 주고받는 방식 (Server - Client 모델)
• 클라이언트와 서버 사이에서 클라이언트가 메시지(요청, Request)를 주고, 서버가 메시지를 받아서 응답(Response)을 주는 형태의 통신 방법

URI(Uniform Resource Identifier)

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

HTML (Hyper Text Markup Language)

• 하이퍼미디어 포맷
• XML을 바탕으로 한 범용 문서 포맷
• 이를 이용하여 사용자가 알아보기 쉬운 형태로 표현

브라우저가 웹 페이지를 보여주는 과정

1. 브라우저 주소창에 naver.com을 입력한다
2. 브라우저가 DNS 를 통해 naver.com의 IP를 확인한다
3. 브라우저는 서버에게 HTTP GET Request 를 보낸다
4. 서버가 html을 만들어 브라우저에게 HTTP Response 를 보낸다
5. 브라우저는 받은 html을 읽으며 렌더링 한다
   1. 이 과정에서 html 내의 html, css ,js, image 등의 자원 링크를 발견하면 자원에 대한 HTTP GET Request를 재귀적으로 보낸다

도메인에 해당하는 IP를 찾는 과정

1. OS의 hosts 파일 탐색 - DNS Client 탐색
2. 만약 hosts 파일에 해당 도메인이 존재하지 않으면, 차근차근 상위 DNS Server에 해당 도메인을 요청한다.

MVC(Model View Controller)

• 초기 웹 개발
  • PHP, JSP, ASP 같은 서버 측 스크립트 언어
    • HTML + 프로그래밍 언어가 혼재
  • 규모가 커질수록 복잡도가 급격히 증가하여 유지보수 어려움

MVC

• Model

1. 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 한다.
2. 뷰나 컨트롤러에 대해서 어떤 정보도 알지 말아야 한다.
3. 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야만 한다.

• View

1. 모델이 가지고 있는 정보를 따로 저장해서는 안된다.
2. 모델이나 컨트롤러와 같이 다른 구성요소들을 몰라야 된다.
3. 변경이 일어나면 변경통지에 대한 처리방법을 구현해야만 한다.

• Controller

1. 모델이나 뷰에 대해서 알고 있어야 한다.
2. 모델이나 뷰의 변경을 모니터링 해야 한다.
3. 사용자의 입력값을 검증해야 한다.

• MVC Framework

1. MVC 기반 구조를 직접 구현 -> 생산성 저하
2. boilerplate code 를 줄이기 위해 등장

• MVC 프레임워크의 종류
  • Spring
  • 장고
  • Nest.js
  • Express.js

HTTP-Network

HTTP

• HTTP/2.0 까지는 TCP, HTTP/3.0은 UDP 기반의 QUIC 사용
• 기본 포트
  • HTTP: 80
  • HTTPS: 443

HTTP 참여자

• Client: 서버에 컨텐츠를 요청
• Server: 클라이언트의 요청에 대한 응답
• Proxy: 클라이언트와 서버 사이에 존재.
  • 오가는 데이터에 대해 캐싱, 필터링, 로드 밸린싱, 인증, 로깅 등 기능 제공

HTTP 특징

• 간단하다
• 상태가 없다. 매 요청은 새로운 요청이다.
  • 인증을 위해 추가적인 정보 필요
    • Authentication Header
    • Cookie - Session

DNS 동작 원리

Query Process Type

• Iterative Query
  • Header RD bit: 0
  • 응답으로 또 다른 DNS의 IP 알려줌
    • 해당 IP에 새로운 DNS Query를 날리는 과정을 반복
      • 응답으로 도메인의 IP를 받으면 멈춤
• Recursive Query
  • Header RD bit: 1
  • 응답으로 도메인의 IP를 알려줌
  • DNS 서버가 내부적으로 Iterative Query를 수행함.

DNS Server Type

• Local DNS
  • PC 가 직접 통신하게 되는 DNS 서버
  • 주로 통신사 기지국 DNS
  • PC를 대신해 iterative query 수행
• Root DNS
  • ICANN이 직접 관리
  • TLS DNS 서버 IP를 저장해두고 안내
• Top-Level DNS
  • 도메인 네임 마지막 segment 를 담당하는 서버 ex) .com
  • Authoritative DNS 서버 IP를 저장해두고 안내
• Authoritative DNS
  • 실제 개인 도메인과 IP 주소의 관계가 저장되어 있는 서버

PC가 DNS 를 통해 www.naver.com IP를 얻는 과정

1. PC의 DNS 캐시에 www.naver.com IP가 있는지 확인한다.
2. 없다면 Local DNS 서버에 www.naver.com에 대한 Recursive Query를 보낸다.
   1. Local DNS 서버는 캐시에 www.naver.com IP가 있는지 확인한다
   2. 없다면 Root DNS에 www.naver.com에 대한 Iterative Query를 보낸다.
      1. 응답으로 .com Top-Level DNS IP를 받는다
   3. .com Top-Level DNS에 www.naver.com에 대한 Iterative Query를 보낸다.
      1. 응답으로 naver.com Authoritative DNS IP를 받는다
   4. naver.com Authoritative DNS에 www.naver.com에 대한 Iterative Query를 보낸다.
      1. 응답으로 www.naver.com에 대한 IP를 받는다.
   5. 서버의 캐시에 www.naver.com 의 IP를 저장한다
   6. PC에게 www.naver.com 의 IP를 보낸다

HTTP 메소드

• GET
  • 데이터를 조회를 요청하는 메소드
  • 멱등성을 보장해야 한다.
  • 리턴값이 캐시 가능하다.
• POST
  • 데이터의 처리를 요청하는 메소드
  • 타깃 리소스의 정의대로 처리된다.
  • 클라이언트가 요청하면, 서버에서 모든 걸 알아서 처리하도록 한다.
  • 멱등성을 보장하지 않아도 된다.
  • 리턴 값이 캐시 가능하지만, Body까지 캐시 키로 고려해야 해서 잘 쓰이지 않는다.
• PUT
  • 데이터의 덮어쓰기를 요청하는 메소드
  • 클라이언트가 서버 내 파일의 위치를 알고있어야 한다.
  • 리소스 전체를 업데이트한다.
  • 멱등성을 보장해야 한다.
• PATCH
  • 데이터의 부분 업데이트를 요청한다.
  • 클라이언트가 서버 내 파일의 위치를 알고있어야 한다.
  • 멱등성을 보장하지 않아도 된다.
  • 리턴 값이 캐시 가능하지만, Body까지 캐시 키로 고려해야 해서 잘 쓰이지 않는다.
• DELETE
  • 데이터의 삭제를 요청한다.
  • 멱등성을 보장해야 한다.
    • “리스트의 마지막 데이터를 삭제해줘”같은 메소드가 있으면 안된다.

참고: 캐시 가능 여부

• 클라이언트가 요청 시, 서버에 바로 요청을 보내지 않고, 내부에 저장된 캐시 메모리를 이용할 수 있는지 여부
• 주의: 서버가 서버 내부에서 캐싱하는 걸 의미하는 게 아님.

참고 2: 멱등성

• 메소드 f에 대하여 f(f(x)) = f(x) 인 성질
• 자신이 아닌 다른 메소드에 의해 결과가 달라지는 것은 고려하지 않는다.

웹 폼을 이용한 대용량 파일 전송의 동작 방식은 어떻게 될까?

• 파일 업로드에서 이미지와 이미지에 대한 설명을 한번에 전송한다고 가정.
• 이때 HTTP Request body에 두 종류에 데이터가 들어가야 한다.
• 데이터의 content type이 image/jpeg, text/html로 다르기 때문에 사용하는 것이 multipart

multipart의 사용 구조

• header에서 content-type을 multipart로 설정
  • Content-Type: multipart/form-data ; boundary=바운더리로 사용할 문자열
• boundary: body에 여러 데이터를 담아야 하기 때문에 구분을 위해 사용하는 문자열
• body의 시작과 끝, 데이터 사이에 boundary로 지정한 문자열 사용
• body에 각 데이터에 대한 정보로는 Content-Disposition, Content-Type 등이 들어갈 수 있음
  • Content-Disposition: form-data; name="image1"
  • Content-Type: image/jpeg
• 참고 - Content-Disposition
  • 일반적 HTTP Response: 웹 페이지에 inline 되는 데이터인지 or 다운로드 받아야하는 attachment 데이터인지
  • multipart/form-data: 현재 필드에 대한 정보

Cookie와 Session

상태성 vs 무상태성

• HTTP는 기본적으로 상태를 갖지 않는다.
  • 어느 서버에서 요청을 처리하든지 동일하게 처리할 수 있도록.
  • 특수하게 WebSocket이라는 기술을 활용해 상태도 지원하긴 한다.
• 클라이언트를 구분할 방법이 필요하다.

쿠키

• 서버에서 클라이언트를 구분하기 위한 방법으로 사용하기 위한 헤더.
• 클라이언트가 자신의 정보를 “쿠키”라는 헤더에 담아 보내도록 만든다.
• 서버는 클라이언트가 전송한 Cookie 헤더 값에 따라 해당 사용자가 누군지를 확인한다.

세션

• 세션 방식
  • 쿠키에 사용자의 중요 정보들을 담으면, 유출의 가능성이 있다.
  • 사용자의 중요 정보는 내부 DB에 저장하고, 서버는 의미를 갖지 않는 UUID와 같은 값들을 사용해서 사용자를 식별한다.
• 세션
  • 위에서 이야기한 “내부 저장소”를 세션이라고 한다.
  • 서버는 클라이언트가 전송한 쿠키 내 Session Id를 활용해 서버에 저장된 값을 꺼내와 사용한다.

주요 헤더

• Secure
  • HTTPS 요청에만 쿠키를 담아서 보내도록 하는 헤더
• Http-Only
  • XSS 공격 방지
  • 자바스크립트로 쿠키에 접근하지 못하도록 하는 헤더.
• Same-Site
  • CSRF 공격을 막기 위한 헤더.
  • 요청한 도메인과 쿠키에 설정된 도메인이 같은 경우에만 해당 쿠키 전송