Part.2 HTTP

📌 이 글을 왜 쓰는가
사실 이 글을 쓰기 위해 웹 서버란 무엇인가를 작성했다. 평소 네트워크에 관심이 많아 통신을 어떻게 하는지 또 백엔드 API get, post 등의 원리가 정확히 이해되지 않았는데 마침 김영한님의 강의가 눈에 띄었고 지금 이걸 공부해도 되나? 싶은 타이밍이었지만 궁금할 때 해둬야 언젠가 쓰리 하며 쿨결제 후 바로 5h30m 시청을 했다. 사실 마지막 API 설계, 상태 코드, 헤더 등은 다시 한번 봐야겠지만 그래도 뭐, http를 정확히 안 것만으로 첫 공부는 성공이다! 고로 그 내용을 정리해 보려 한다.

네트워크 관리사 공부 다시 해야하는..

 

🔥 강의 정보: 모든 개발자를 위한 HTTP 웹 기본 지식

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC

1. 인터넷 네트워크

• 인터넷상에서 어떤 식으로 통신이 일어나는가
• 어떤 규칙으로 목적지까지 안전하게 도착할까?
• IP, TCP, UDP, PORT, DNS 등 인터넷 네트워크에 대해서 공부해볼 테다

1-1. IP

• ip(인터넷 프로토콜): 최소한의 규칙
  • 지정한 ip주소에 데이터 전달(패킷)
  • 왔다 갔다 루트가 다를 수 있다.
  • 한계: 비연결성(대상이 서비스 불능인데 패킷 전송), 비신뢰성(중간 서버가 문제 생겨서 패킷 소실), 프로그램 구분 X(패킷 전달 순서 문제 발생)
  • 이걸 해결해 주는 게 TCP
• ip 위에 tcp를 얹어서 보완해준다.
• 프로토콜 계층: 애플리케이션, os, 네트워크 인터페이스
  
  

1-2. TCP

• TCP segment: 출발지 port, 목적지 port, 전송 제어, 순서, 검증 정보 등이 들어간다.
• TCP(전송 제어 프로토콜) 특징: 연결 지향(연결 확인), 데이터 전달 보증(중간에 누락되면 내가 알 수 있다), 순서 보장, 신뢰할 수 있는 프로토콜, 현재는 대부분 tcp 사용
  • 연결 지향: TCP 3 way handshake(가상연결임)
    SYN(접속 요청) -> SYN(연결 왔어? 오케 나도 연결 갈게 응답) -> ACK(요청 수락) -> ACK(응 나도 요청수락) -> 데이터 전송
  • 데이터 전달 보증: 데이터 전송 -> 데이터 잘 받았음이라고 보내줌(응답 잘해준다)
  • 순서 보장: 순서 잘못 가면 클라이언트한테 서버가 "야 패킷 2부터 다시 보내"하고 알려줌

1-3. UDP

• UDP(사용자 데이터그램 프로토콜) 특징: 하얀 도화지에 비유(기능이 거의 없음) 하지만, +port(하나의 ip에서 어떤 애플리케이션으로 보내야 하는지 아는 것) + 체크섬(메시지 검증 데이터) 정도만 추가 so 애플리케이션에서 추가 작업 필요
• tcp 3 way handshake 하려면 시간이 걸린다, 그리고 데이터 다 넣고 하면 데이터 양도 크고 전송속도도 빠르게 하기 어렵다. 즉 tcp는 이미 손을 못 댄다. 그래서 더 최적화하려고 udp에 손을 대는 것
• http3 스펙이 udp프로토콜 쓰면서 굉장히 뜨고 있음

1-4. PORT

• 클라이언트 pc가 한 번에 두 개 이상 서버와 연결해야 하면?
• port: ip는 목적지 서버를 찾는 것, port는 서버 안에서 돌아가는 애플리케이션을 찾는 것 즉 같은 ip 내에서 프로세스 구분하는 것( ip는 아파트 port는 몇 동 몇 호)
• port: 0 ~ 65535 할당 가능/ 0 ~ 1023 잘 알려진 포트, 사용하지 않는 것이 좋음/ FTP 20,21/ TELNET 23/ HTTP 80/ HTTPS 443

1-5. DNS

• ip는 기억하기 어렵다. 그리고 변경될 수도 있음.
• DNS(도메인 네임 시스템): 전화번호부 같은 서버를 제공, 도메인 명을 ip주소로 변환해 줌
• 클라이언트가 DNS 서버에 도메인 명 등록 -> ip주소로 응답 -> 클라이언트가 서버로 접속

1-6. URI

• URI(uniform Resource Identifier): resource를 식별하는 통합된 방법
• URI: URL/ URN: URI는 로케이터(locator)(김서현이 여기에 있어요)(리소스가 있는 위치를 지정), 이름(name)(김서현)(리소스에 이름을 부여). (doc참고)
• URL: scheme(프로토콜 정보) - authority(호스트명) - path(포트번호, 경로) - query(쿼리 파라미터) - fragmnet
  : scheme://[userinfo@]host[:port][/path][?query][#fragment]
  • 스키마: 주로 프로토콜 사용, 어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙/ http는 80포트, https는 443포트를 주로 사용, 포트는 생략 가능
  • 호스트명: 도메인명 또는 ip명 직접 입력
  • 포트: 접속 포트 일반적으로 생략
  • path: 리소스 경로, 계층적 구조
  • query: key=value 형태/ ?로 시작, &로 추가 가능/ query parameter, query string 등으로 불림, 웹서버에 제공하는 파라미터, 문자 형태(숫자를 적어도 문자로 넘어간다)
  • fragment: 잘 사용하진 않는데 html 내부 북마크 등에 사용, 서버에 전송하는 정보 아님
• URN:scheme - path
• 위치는 변할 수 있지만, 이름은 변하지 않는다. urn 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화되지 않음. 그러니 앞으로 uri를 url과 같은 의미로 이야기하겠음

1-7 웹 브라우저 요청 흐름

1. 웹 브라우저 요청 흐름: 웹 브라우저 오픈 -> DNS 조회 -> ip 나옴 -> port 정보 찾음 -> http 요청 메세지 생성 -> http 메세지 전송(웹브라우저 -> socket 라이브러리를 통해 전달(tcp/ip 연결-> 데이터 전달) -> tcp/ip 패킷 생성, http 메세지 포함-> 인터넷-> 서버)
2. 요청 패킷 전달(인터넷망으로 던지고 노드를 통해서 서버로 감) -> 요청 패킷 도착(tcp/ip 패킷 다 까서 버리고 http 메시지만 끄집어내서 해석을 한다) -> 서버에서 http 응답 메시지를 만들어 냄(content-type 중요) -> 패킷 씌우고 또 웹브라우저에 응답 보냄 -> 웹브라우저가 응답 메세지를 받고 까서 바로 웹브라우저 html 렌더링 -> 우리가 본다

2. 모든 것이 HTTP

1. http(hypertext transfer protocol): 거의 모든 형태의 데이터를 전송 가능, 서버 간에 데이터를 주고받을 때도 대부분 http 사용/ 1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전/2 2015년: 성능 개선/ 3 진행 중: tcp 대신에 udp 사용, 성능 개선에 초점
2. 기반 프로토콜: http 1.1 주로 사용(이 스펙을 잘 알면 됨), 2와 3도 점점 증가( f11 눌러서 protocol 보면 h2, h3 볼 수 있음)
3. 특징: 클라이언트-서버 구조/ 무상태 프로토콜(스테이스 리스), 비연결성, http 메시지, 단순함, 확장 가능

2-1. 클라이언트 - 서버 구조

1. 클라이언트-서버 구조
   :request response 구조
   :클라이언트는 서버에 요청을 보내고, 응답을 대기
   :서버가 요청에 대한 결과를 만들어서 응답
2. 클라이언트와 서버를 개념적으로 분리하는 게 중요함, 비즈니스 로직, 데이터 같은 건 서버에 다 넣고, ui랑 사용성을 클라이언트에 집중. 각각 독립적으로 발전할 수 있다. 비즈니스가 잘돼서 트래픽이 폭파되면 서버의 아키텍처, 백엔드 고도화를 고민하면 됨. 클라이언트는 건들 필요 없이.

2-2. Stateful, Stateless

1. 무상태 프로토콜(스테이트리스 stateless)

• 서버가 클라이언트의 상태를 보존하지 않는다: stateful과 stateless의 차이. 백화점에서 한 셀러한테 도움받으면 context를 보전, 갑자기 셀러가 중간에 바뀌면 context 보전이 안됨.

상태 유지에서 중간에 점원이 바뀌면 꼬인다. 상태 정보를 바뀐 점원에게 미리 다 알려줘야 하니까. 근데 무상태에서 중간에 점원이 바뀌어도 된다. 갑자기 고객이 증가해도 점원을 대거 투입할 수 있다. 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다. 즉 무상태는 응답 서버를 쉽게 바꿀 수 있다 -> 무한한 서버 증설 가능

• stateful(상태 유지): 항상 같은 서버가 유지되어야 한다. 그래서 이 서버가 죽으면 응답이 오지 않음

• stateless(무상태): 아무 서버나 호출해도 된다. 그래서 서버 1번이 장애가 나도 클라이언트 요청을 중계서버가 서버 2번으로 던질 수 있다.

so, 스케일 아웃(서버를 수평으로 확장하는 것)이 가능하고 유리함. 이벤트 페이지가 있으면 장비를 수백 대 팍 늘려버리면 끝~

but, 실무 한계가 있다

• 모든 것을 무상태로 설계할 수 있는 경우도 있고 없는 경우도 있다.
• 무상태: 로그인이 필요 없는 단순한 서비스 소개 화면/ 상태 유지: 로그인
• 로그인한 사용자의 경우 로그인했다는 상태를 서버에 유지(브라우저에 있는 쿠키와 서버의 세션을 조합해서 상태를 유지하는 기능을 쓴다. 세션 서버가 죽어버리면 로그인이 풀린다. 그래서 상태 유지는 최소한만 사용)
• stateful 보다 데이터를 너무 많이 보낸다.

2-3. 비 연결성(connectionless)

1. 비연결성(connectionless)

• 서버가 연결을 계속 유지하면 서버 자원을 소모할 수밖에 없다. 근데 클라이언트와 서버가 연결을 계속 유지하지 않아도 되면 즉 요청할 때만 연결을 하면 된다면 서버는 최소한의 자원만 유지하면 된다.
• http는 기본이 연결을 유지하지 않는 모델
• 일반적으로 초 단위의 이하의 빠른 속도로 응답
• 1시간 동안 수천 명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십 개 이하로 매우 작음
• 서버 자원을 매우 효율적으로 사용할 수 있음
• but 단점이 있다.
• tcp/ip 연결을 새로 맺어야 함 : 3 way handshake 시간 추가
• 웹 브라우저로 사이트를 요청하면 html뿐만 아니라 js, css, 추가 이미지 등 수많은 자원이 함께 다운로드
• 지금은 http 지속 연결(persistent connections)로 문제 해결
• http/2, http/3에서 최적화됨(초기와 지금 비교할 것)(연결-요청-응답 연결-요청-응답 이랬는데 연결-요청-응답-요청-응답-종료 이렇게 됨)

2. 스테이스리스를 기억하자(서버 개발자들이 어려워하는 업무)

• 정말 같은 시간에 딱 맞추어 발생하는 대용량 트래픽: 이땐 진짜 수만 명이 동시 요청임 이때는! 어떻게든 스테이스리스하게 설계하는 게 중요함! 대응방법이 많아짐! 어쩔 수 없는 부분에 대해서만 상태 유지하게 설계하는 게 중요함

so, 첫: 정적 페이지(순수 html) - 이벤트 참여 버튼 누르게

2-4. HTTP 메시지

1. http 메시지 구조: 시작 라인 - 헤더 - 공백 라인 - message body (요청/응답 메시지 기본 구조)
2. 시작 라인(요청 메시지는 리퀘스트 라인)

• request-line: method(get, post..) SP(공백) request-target SP HTTP-version CRLF(엔터)
• • method: GET 리소스 조회/ POST 요청 내역 처리, PUT< DELETE ...
• • request-target: absolute-path[?query]( 절대 경로 "/"로 시작하는 경로)
• • HTTP 버전 넣음

3. 시작 라인(응답 메시지는 status-line)

• status-line: HTTP-version SP status-code SP reason-phrase CRLF(엔터)
• • status-code: 요청 성공, 실패를 나타냄(200 성공, 400 클라이언트 요청 오류, 500 서버 내부 오류)
• • 이유 문구: 사람이 이해할 수 있는 문구 써줌

4. 헤더

: header-field = field-name":"OWS fidel-value OWS (OWS: 띄어쓰기 허용)(fiedl-name은 대소문자 구문 없음, value는 있음)
: http전송에 필요한 모든 부가정보가 다 들어있다/ 표준 헤더가 너무 많음/ 필요시 임의의 헤더 추가 가능

5. 메시지 바디: 실제 전송할 데이터, 모든 데이터 전송 가능
6. http는 단순함. 스펙도 읽어볼 만.. 메시지도 매우 단순함. 크게 성공하는 표준 기술은 단순하지만 확장 가능한 기술임

3. HTTP API를 만들어보자

1. http API: 첫 단계, api url 설계 (가장 중요한 것은 리소스 식별)

• 리소스의 의미는 뭘까? 회원이라는 개념 자체가 바로 리소스다.
• 리소스를 어떻게 식별하는 게 좋을까? 회원이라는 리소스만 식별하면 된다 -> 회원 리소스를 url에 매핑
• 계층 구조상 상위를 컬렉션으로 보고 복수 단어 사용 권장
• 리소스와 행위를 분리해야 한다. 가장 중요한 건 리소스를 식별하는 것 그러니 uri는 리소스만 식별, 행위는 어떻게 구분?

3-1. HTTP 메서드 - GET, POST

• http 메서드 종류
  • GET: 리소스(representation) 조회
  • POST: 요청 데이터 처리, 주로 등록에 사용
  • PUT: 리소스를 대체, 해당 리소스가 없으면 생성
  • PATCH: 리소스 부분 변경
  • DELETE: 리소스 삭제
  • 기타 메서드: HEAD(GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환), OPTIONS(대상 리소스에 대한 통신 가능 옵션을 설명), CONNECT(대상 자원으로 식별되는 서버에 대한 터널을 설정), TRACE( 커넥트랑 트레이스는 거의 안 쓰임)

1. GET

• 리소스 조회
• 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
• 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음
• 지원하지 않는 서버가 많다. 보통 메시지 바디를 잘 허용하지 않아서 서버가 처리 안 하는 경우가 많기 때문에

2. POST

• 클라이언트가 서버한테 데이터를 전달할 테니까 이 요청 데이터를 처리해줘 라는 것(메시지 바디를 통해)
• 서버는 요청 데이터를 처리(메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행)
• 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용
• 어떻게 처리한다는 뜻일까? 정해진 것이 없고 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 한다.
• 주로 새 리소스를 생성하고 등록/ 요청 데이터를 처리(이게 중요함, 단순히 데이터를 생성하거나 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우, post의 결과로 새로운 리소스가 생성되지 않을 수도 있음)/ 다른 메서드로 처리하기 애매한 경우

3. put

• 리소스가 있으면 완전히 대체(수정이 아니라 완전히 갈아치우는 거임), 리소스가 없으면 생성, 쉽게 이야기해서 덮어버림
• 클라이언트가 리소스를 식별(중요!!), 클라이언트가 리소스 전체 위치를 알고 uri지정(post와 큰 차이점)

4. patch

• 리소스 부분 변경
• but 지원 안 되는 서버도 있다(드묾) 그럴 경우 post 써야 함

5. delete

• 리소스 제거

3-2. HTTP 메서드의 속성

1. http 메서드의 속성

• 안전(safe): 호출해도 리소스를 변경하지 않는다.
• Q) 계속 호출해서, 로그 같은 게 쌓여서 장애가 발생하면?
  A) 안전은 해당 리소스만 고려한다. 그런 부분까지 고려 ㄴ
  • 단, get만 안전함. 나머진 다 바꾸는 거니까 안전하지 않음
• 멱등(idempotent): 한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다 (get, put: 결과를 대체하니까 같은 요청을 여러 번 해도 최종 결과는 같음, delete/ post 멱등이 아니다! 두 번 호출하면 같은 결제가 중복해서 발생할 수 있음)
• 자동복구 메커니즘에 쓸 수 있음, 서버가 타임아웃 등으로 정상 응답을 못 주었을 때, 클라이언트가 같은 요청을 다시 해도 되는가? 의 판단 근거 (delete는 똑같은 요청을 두 번 해도 된다)
• Q)재요청 중간에 다른 곳에서 리소스를 변경해버리면?
  A)멱등은 외부요인으로 중간에 리소스가 변경되는 것 까지는 고려하지는 않는다. (중간에 변경된 리소스로 나옴)
• 캐시 가능(cacheable): 응답 결과 리소스를 캐시 해서 사용해도 되는가?/ get, head, post, patch 캐시 가능/ 실제로는 get, head 정도만 캐시로 사용(똑같은 리소스와 키가 맞아야 하는데 post는 복잡해서 구현이 잘 안됨)/ post, patch는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않음

3-4. 클라이언트에서 서버로 데이터 전송

클라이언트에서 서버로 데이터 전송하는 방법은 크게 2가지

1. 쿼리 파라미터를 통한 데이터 전송

• get
• 주로 정렬 필터(검색어)

2. 메시지 바디를 통한 데이터 전송

• post, put, patch
• 회원가입, 상품 주문, 리소스 등록, 리소스 변경

4가지 상황

1. 정적 데이터 조회: 쿼리 파라미터 미사용/클라이언트에서 서버로 이미지 리소스 경로로 그냥 내려줌. 추가적인 데이터가 없음
2. 동적 데이터 조회: 쿼리 파라미터 사용/ 쿼리 파라미터를 기반으로 정렬 필터에서 결과를 동적으로 생성/ 주로 검색, 게시판 목록에서 정렬 필터(검색어)/ 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용/ 조회는 get 사용/ get은 쿼리 파라미터 사용해서 데이터를 전달
3. html form을 통한 데이터 전송: 뭐라는지 모르겠다! 웹서버 파싱? 잘 모르겠다!

method="post, get" 둘 다 됨

4. http api를 통한 데이터 전송

모르겠다!

3-5. HTTP API 설계

결론: api url 어떻게 설계할 것인가