[인프런 김영한 로드맵3]모든 개발자를 위한 HTTP 웹 기본 지식1

- 김영한님의 인프런강의 '모든 개발자를 위한 HTTP 웹 기본 지식'을 학습하고 정리한 내용이다.

- HTTP 웹 기본 지식과 관련된 내용을 학습힌다.

- 모든 내용 및 이미지 출처는 인프런 및 김영한님에게 있습니다.

---

1.인터넷 네트워크

 

• 인터넷에서 클라이언트와 서버는 서로 통신 함
• 보내는 쪽(클라이언트)은 서버 정보를 알아야 보낼 수 있음 -> IP
• IP를 통해 데이터 전달
• 패킷이라는 통신단위로 데이터 전달
• IP패킷에는 출발지IP, 도착지IP, 기타정보로 구성
• 클라이언트가 도착지IP에 패킷 전달하면 서버는 출발지IP를 확인 후 OK 응답 등을 보냄
• IP 프로토콜의 한계
  • 1)비연결성 : 패킷 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송
  • 2)비신뢰성 : 중간에 패킷이 사라지거나 패킷 순서가 변경되는 경우 발생
  • 3)프로그램 구분 : 서버에 애플리케이션이 2개 이상이면?
• IP 프로토콜 한계를 극복하기 위한 TCP 탄생
• 우선 인터넷 프로토콜 스택 4계층을 알아야 함(하단 이미지 참고)
  • cf)네트워크 전송시 데이터 표준을 정리한 것이 OSI 7계층, 이 이론을 실제 사용하는 인터넷표준이 TCP/IP 4계층

 

이미지출처 : 김영한님 강의 자료

 

• IP한계를 극복한 TCP/IP모델의 통신 순서
  • 1)프로그램이 Hello, world! 메시지 생성(애플리케이션 계층)
  • 2)SOCKET 라이브러리를 통해 전달(애플리케이션계층)
  • 3)TCP정보 생성, 메시지 데이터 포함(전송계층)
  • 4)IP패킷생성, TCP데이터 포함(인터넷계층)
  • 5)LAN카드를 통해 서버로 전달(네트워크 인터페이스 계층)
• TCP/IP패킷정보의 TCP 부분에 출발지PORT, 목적지PORT, 전송제어, 순서, 검증정보 등 존재
• TCP 특징
  • 1)연결지향 : 3 way handshake
    • SYN : 접속 요청
    • ACK : 요청 수락(ACK와 함께 데이터 전송 가능)
  • 2)데이터 전달 보증
  • 3)순서 보장
    • 패킷1,패킷2,패킷3순서로 전송했는데 서버가 패킷1,패킷3,패킷2로 받으면?
      • 서버에서 패킷2부터 재전송 요청을 클라이언트에게 응답
• UDP라는 것도 있음. UDP 특징
  • 하얀 도화지에 비유(기능 거의 없음)
  • 연결지향X,데이터전달보증X, 순서보장X
  • but, 단순하고 빠름
  • IP와 거의 같지만 PORT, 체크섬 정도 추가
  • 애플리케이션 추가 작업 필요
• PORT
  • PORT는 같은 IP내에서 프로세스 구분(프로세스는 실행되는 프로그램)
• DNS
  • IP는 기억하기 어려움 + 변경 가능성
  • 전화번호부같은 시스템 필요
  • 도메인명을 IP주소로 변환해주는 시스템
  • google.com 요청시 DNS서버에서 IP(200.200.200.2)를 알려주면 이 IP를 통해 서버 접근

 

 

2.URI와 웹 브라우저 요청 흐름

 

1)URI

• URI, URL, URN
  • URI : Uniform Resource Identifier
  • URL : Uniform Resource Locator
  • URN : Uniform Resource Name
• URI가 가장 큰 개념
• URI뜻
  • Uniform : 리소스를 식별하는 통일된 방식
  • Resource : 자원, URI로 식별할 수 있는 모든 것(제한 없음)
  • Identifier : 다른 항목과 구분하는데 필요한 정보
• URN 이름만으로 실제 리소스 찾기 보편화되지 않음
• URL, URI 같은 의미로 많이 사용
• URL 분석
  • https://www.google.com/search?q=hello&hl=ko
  • scheme://[userinfo@]host[:port][/path][?query][#fragment]
  • scheme
    • 주로 프로토콜을 사용. 프로토콜은 어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙
    • http, https, ftp 등
    • http는 80, https는 443 기본 포트(생략가능)
    • http + secure = https
  • userinfo
    • URL에 사용자정보 포함해서 인증
    • 거의사용X
  • host
    • 호스트명
    • 도메인명 또는 IP주소를 직접 사용가능
  • port
    • 접속 포트
  • path
    • 리소스 경로. 계층적 구조
  • query
    • key=value형태
    • ?로 시작. &로 추가 가능 ex)keyA=valueA&keyB=valueB
    • 쿼리파라미터, 쿼리스트링으로 불림
  • fragment
    • html 내부 북마크 등에 사용(서버에 전송하는 정보 X)

 

 

 

2)웹 브라우저 요청 흐름

 

https://www.google.com/search?q=hello&hl=ko 요청을 보내려고한다. 요청시 웹 브라우저가 HTTP 메시지를 다음과 같이 생성한다.

 

 

SOCKET 라이브러리를 통해 전달한다. TCP/IP로 연결되어 패킷생성 및 HTTP메시지를 다음과 같이 포함한다. 

 

 

네트워크인터페이스(물리계층)를 통해 서버로 전달된다. 서버는 다음과 같은 응답메시지를 보낸다.

 

 

 

3.HTTP

 

1)모든 것이 HTTP

• HTTP 메시지에 모든 것을 전송
• HTML, TEXT, IMAGE, 음성, 영상, 파일..
• JSON, XML(API)
• 거의 모든 형태의 데이터 전송 가능
• 서버간에 데이터 주고받을 때도 대부분 HTTP를 사용
• HTTP역사
  • HTTP/0.9부터 HTTP/3까지 진행중..
  • HTTP/1.1을 가장 많이 사용
• 기반 프로토콜
  • TCP:HTTP/1.1, HTTP/2
  • UDP : HTTP/3
  • 현재 HTTP/1.1 주로 사용(HTTP/2, HTTP/3도 점점 증가)
• HTTP 특징
  • 클라이언트 서버 구조
  • 무상태 프로토콜(stateless), 비연결성
  • HTTP 메시지
  • 단순함, 확장가능

 

2)클라이언트 서버 구조

• Request, Response 구조
• 클라이언트가 서버에 요청, 서버가 클라이언트에 응답

 

3)Stateful, Stateless

• 무상태 프로토콜(stateless)
  • 서버가 클라이언트 상태를 보존하지 않음
  • 장점 : 서버 확장성 높음(scale out)
  • 단점 : 클라이언트 추가 데이터 전송 필요
• stateful, stateless 차이 예시
  • stateful
    • 노트북 구매시 점원이 중간에 바뀌면 고객 말을 못알아 듣는다.
    • 항상 같은 서버가 유지되어야함. 서버1에 요청을 보내면 서버1에만 연결 유지되어야 함
    • 중간에 서버1장애나면 응답 오류..
  • stateless
    • 중간에 다른 점원으로 바뀌어도 됨. (응답서버를 쉽게 바꿀 수 있음)
    • 아무서버나 호출해도 됨. 서버1에 요청보내다가 서버1장애발생시 서버2로 요청 전환
  • 실무한계
    • 로그인 필요없는 서비스 소개 화면 등은 무상태로 설계 가능
    • 로그인 필요한 곳은 상태유지 필요 -> 로그인한 상태를 서버에 유지해야함.
      • 브라우저 쿠키, 서버 세션등을 사용하여 유지
      • 상태 유지는 최소한만 사용

 

4)비연결성(connectionless)

 

• 연결 유지 모델은 클라이언트 요청시 TCP/IP 연결을 하면 종료되도 끊지 않아서 자원 소모
• 연결 비유지 모델은 클라이언트 요청시 서버와 TCP/IP로 연결되지만, 응답이 종료되면 TCP/IP 연결을 종료해서 최소한의 자원 유지
• HTTP는 기본이 연결을 유지하지 않는 모델 → 서버자원을 효율적으로 사용 가능
• 한계
  • TCP/IP연결시 3way handshake 시간 추가
  • 웹브라우저로 사이트 요청시 HTML, JS, CSS 등 많은 자원이 다운로드
  • HTTP 지속연결로 문제 해결(아래 이미지 참고)
  • HTTP/2, HTTP/3에서 최적화

 

 

 

5)HTTP 메시지

 

HTTP 메시지는 다음과 같이 구성되어 있다.

 

 

 

• 1)start-line : 요청시 request-line, 응답시 status-line
• 2)http header : http 전송에 필요한 모든 부가정보. 메시지바디 내용, 크기, 압축, 인증 등..
• 3)http message body : 실제 전송할 데이터. HTML문서, 이미지, 영상, JSON등 byte로 표현가능한 모든 데이터 전송 가능

 

4.HTTP 메서드

 

1)HTTP API를 만들어보자

 

다음과 같이 회원정보관리 API를 만든다고 가정한다.

• 회원목록조회 /read-member-list
• 회원조회 /read-member-by-id
• 회원등록 /create-member
• 회원수정 /update-member
• 회원삭제 /delete-member

 

좋은 URI 설계에서 중요한 것은 리소스 식별이다. 리소스는 등록, 수정 등의 '행위'가 아니라 회원이라는 개념 자체가 리소스이다. 회원이라는 리소스만 식별하고 등록, 조회 등 모두 배제한다.

 

리소스를 식별하여 URI계층구조를 활용하면 다음과 같이 만들 수 있다.(참고로 계층구조상 상위를 컬렉션으로 보고 복수단어(members) 사용을 권장한다.)

 

• 회원목록조회 /members
• 회원조회 /members/{id}
• 회원등록 /members/{id}
• 회원수정 /members/{id}
• 회원삭제 /members/{id}

 

행위(메서드)인 조회, 등록, 수정 등 어떻게 구분할까? 

 

2)HTTP 메서드 - GET, POST

 

HTTP 메서드 종류는 다음과 같다.

• GET : 리소스 조회
• POST : 요청 데이터 처리. 주로 등록에 사용
• PUT : 리소스를 대체. 해당 리소스 없으면 생성
• PATCH : 리소스 부분 변경
• DELETE : 리소스 삭제

 

기타 다음과 같은 메서드도 있다.

• HEAD, OPTIONS, CONNECT, TRACE..

 

GET메서드는 다음과 같은 특징을 가진다.

• 리소스 조회
• 서버에 전달하고 싶은 데이터는 query(쿼리파라미터, 쿼리스트링)로 전달
• 메시지 바디를 사용하여 전달 가능하지만 지원하지않는 곳이 많아 권장 안 함

 

POST메서드는 다음과 같은 특징을 가진다.

• 요청 데이터 처리
• 메시지 바디를 통해 서버로 요청 데이터 전달
• 서버는 요청 데이터 처리
• 신규 리소스 등록, 프로세스 처리 등에 사용
• JSON으로 조회 데이터 넘겨야 하는데 GET 메서드 사용이 어려운경우 POST 사용하기도 함

 

3)HTTP 메서드 - PUT, PATCH, DELETE

 

PUT은 다음과 같은 특징을 가진다.

• 리소스를 대체(리소스가 있으면 대체, 없으면  생성)
• 리소스를 덮어버린단 의미
• POST와의 차이점 → 클라이언트가 리소스 위치를 알고 URI 지정

PATCH와의 차이점은?

• PUT은 완전변경 / PATCH는 부분변경
• members/100 데이터가 {"username" : "young", "age": 20}이라고 가정할 떄..
  • PUT으로 {"age":50}을 보내면 members/100데이터는 {"age":50}으로 덮힘
  • PATCH로 {"age":50}을 보내면 members/100데이터는 {"username": "young", "age":50}으로 변경

 

DELETE는 리소스를 제거한다. 

 

 

4)HTTP 메서드의 속성

• 안전(Safe Methods)
  • 호출해도 리소스 변경 안 함
  • 안전메서드 : GET, HEAD
• 멱등(Idempotent Methods)
  • f(f(x)) = f(x)
  • 한 번 호출하든 두 번 호출하든 100번 호출하든 결과 같음
  • 멱등메서드 : GET, PUT, DELETE
  • POST는 멱등이 아님. 두 번 호출시 같은 결제가 중복해서 발생할 수 있음
  • 자동복구메커니즘 등에 활용가능 → 서버가 TIMEOUT 등으로 정상응답 못줬을 때 클라이언트가 같은 요청을 해도 되는지에 대한 판단 근거
  • 멱등은 외부요인으로 중간에 리소스 변경되는 것까지 고려X
• 캐시가능(Cacheable Methods)
  • 응답 결과 리소스를 캐시해서 사용해도 되는가?
  • GET, HEAD, POST, PATCH 캐시 가능
  • 실제로는 GET, HEAD 정도만 캐시로 사용

 

 

5.HTTP 메서드 활용

 

1)클라이언트에서 서버로 데이터 전송

 

데이터 전달방식은 크게 2가지가 있다.

• 1)쿼리파라미터 : GET 전송. 주로 정렬필터(검색)
• 2)메시지바디 : POST, PUT, PATCH 전송. 회원가입, 상품주문, 리소스 등록 등

 

데이터 전송의 4가지 상황이 있다.

• 1)정적데이터 조회 : 이미지, 정적텍스트 문서
• 2)동적데이터 조회 : 검색, 게시판 목록에서 정렬필터
• 3)HTTP Form을 통한 데이터 전송 : 회원가입, 상품주문, 데이터 변경
• 4)HTTP API를 통한 데이터 전송 : 회원가입, 상품주문, 데이터 변경(서버to서버, 앱클라이언트, 웹클라이언트Ajax)

1)과 2)는 쿼리파라미터 방식이고 3)과 4)는 메시지바디에 담는 전달방식으로 생각하자.

 

GET전송은 조회에서만 사용하며 등록시에는 사용하면 안 된다.

 

파일 업로드인 경우 multipart/form-data 인코딩 타입으로 POST요청한다.

• Content-type : multipart/form-data
• 파일업로드같은 바이너리 데이터 전송시 사용
• 다른 종류의 여러 파일과 폼의 내용 함께 전송가능(이름이 multipart)
• HTML Form전송은 GET, POST만 지원

 

2)HTTP API 설계 예시

 

HTTP API 데이터 전송시 POST 등록시와 PUT 등록시 컬렉션과 스토어라는 개념이 나온다.

• 컬렉션
  • POST로 신규자원 등록시..
  • 클라이언트는 등록될 리소스 URI를 모른다. 서버가 새로 등록된 리소스 URI를 생성해준다.
  • ex) /members/100
  • 컬렉션은 서버가 관리하는 리소스 디렉토리이며 여기서 컬렉션은 /members
• 스토어
  • PUT으로 신규자원 등록시..
  • 클라이언트가 리소스 URI를 알고 있어야 한다.
  • ex) files/star.jpg
  • 클라이언트가 직접 리소스 URI를 지정
  • 클라이언트가 관리하는 리소스 저장소. 여기서 스토어는 /files

 

 

HTTP Form 전송과 HTTP API 전송의 차이점은 다음과 같다.

• HTTP Form 전송은 응답결과로 HTML을 받는다.
• HTTP API 전송은 응답결과로 데이터를 받는다.

 

 

 

 

 

참고
https://velog.io/@jehjong/%EA%B0%9C%EB%B0%9C%EC%9E%90-%EC%9D%B8%ED%84%B0%EB%B7%B0-TCPIP-4%EA%B3%84%EC%B8%B5

https://hseungyeon.tistory.com/437?category=1060297