HTTP

TCP

전송 제어 프로토콜(Transmission Control Protocol)

• 연결지향 - TCP 3 way handshake(가상 연결)
  • Connect 연결 과정
    • 1. SYN(접속 요청)
    • 2. SYN+ ACK
    • 3. ACK(요청 수락)
    • 4. 데이터 전송
• 데이터 전달 보증
  • 1. 데이터 전송
  • 2. 데이터 잘 받았음
• 순서 보장
  • 1. 패킷1, 패킷2, 패킷3 순서로 전송
  • 2. 패킷1, 패킷3, 패킷2 순서로 도착
  • 3. 패킷2부터 다시 보내
• 신뢰할 수 있는 프로토콜
• 현재는 대부분 TCP 사용

UDP

사용자 데이터그램 프로토콜(User Datagram Protocol)

• 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름

Port

• 0 ~ 65535 할당 가능
• 0 ~ 1023 : 잘 알려진 포트, 사용하지 않는 것이 좋음
  • FTP -20,21
  • TELNET -23
  • HTTP - 80
  • HTTPS - 443

DNS

도메인 네임 시스템(Domain Name System)

• 전화번호부
• 도메인 명을 IP 주소로 변환

URI

(Uniform Resource Identifier)

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

URL

Uniform Resource Locator

• Locator : 리소스가 있는 위치를 지정
• 전체 문법
  • scheme://[userinfo@]host[:port][/path][?query][#fragment]
  • Https://www.google.com:443search?q=hello&hl=ko
    • 프로토콜(https)
      • 어떤 방식으로 자원에 접근할 것인가 하는 약속 규치
      • http는 80 포트, https는 443 포트를 주로 사용, 포트는 생략 가능
      • https는 http에 보안 추가(HTTP Secure)
    • [userinfo@]
      • URL에 사용자정보를 포함해서 인증
      • 거의 사용하지 않음
    • 호스트명(www.google.com)
      • 도메인명 또는 IP 주소를 직접 사용가능
    • 포트 번호(443)
    • 패스(/search)
      • 리소스 경로(path), 계층적 구조
    • 쿼리 파라미터(q=hello&hl=ko)
      • key=value 형태
      • ?로 시작, &로 추가 기능
      • query parameter, query string등으로 불림
      • 웹서버에 제공하는 파라미터, 문자 형태
    • fragment
      • html 내부 북마크 등에 사용
      • 서버에 전송하는 정보 아님

URN

Uniform Resource Name

• Name : 리소스에 이름을 부여

정적 데이터 조회

• 이미지, 정적 텍스트 문서
• 조회는 GET 사용
• 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능

동적 데이터 조회

• 주로 검색, 게시판 목록에서 정렬필터(검색어)
• 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용
• 조회는 GET 사용
• GET은 쿼리 파라미터 사용해서 데이터를 전달

HTML Form 데이터 전송

• HTML Form submit시 POST 전송
  • 예) 회원 가입, 상품 주문, 데이터 변경
• Content-Type : application/x-www-form-urlencoded 사용
  • Form의 내용을 메시지 바디를 통해서 전송(key=value,쿼리 파라미터 형식)
  • 전송 데이터를 url encoding 처리
    • 예) abc김 -> abc%EA%B9%80
• HTML Form은 GET 전송도 가능
• Content-Type: Multipart/form-data
  • 파일 업로드 같은 바이너리 데이터 전송시 사용
  • 다른 종류의 여러 파일과 폼의 내용 함께 전송 가능(그래서 이름이multipart)
• 참고 : HTML Form 전송은 GET,POST만 지원

HTTP API 데이터 전송

• 서버 to 서버
  • 백엔드 시스템 통신
• 앱 클라이언트
  • 아이폰, 안드로이드
• 웹 클라이언트
  • HTML에서 Form 전송 대신 자바 스크립트를 통한 통신에 사용(AJAX)
  • 예) React, VueJs 같은 웹 클라이언트와 API통신
• POST, PUT, PATCH: 메시지 바디를 통해 데이터 전송
• GET : 조회, 쿼리 파라미터로 데이터 전달
• Content-Type: application/json을 주로 사용(사실상 표준)
  • TEXT, XML, JSON 등등

HTTP API 설계 예시

• HTTP API - 컬렉션
  • POST 기반 등록
  • 서버가 리소스 URI 결정
  • 예) 회원 관리 API 제공
• HTTP API - 스토어
  • PUT 기반 등록
  • 클라이언트가 리소스 URI 결정
  • 예 ) 정적 컨텐츠 관리, 원격 파일 관리
• HTML FORM 사용
  • 순수 HTML + HTML form 사용
  • 웹 페이지 회원 관리
  • GET, POST만 지원

참고하면 좋은 URI 설계 개념

• 참고(document)
  • 단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row)
  • 예) /members/100, /files/star.jpg
• 컬렉션(collection)
  • 서버가 관리하는 리소스 디렉터리
  • 서버가 리소스의 URI를 생성하고 관리
  • 예) /members
• 스토어(store)
  • 클라이언트가 관리하는 자원 저장소
  • 클라이언트가 리소스의 URI를 알고 관리
  • 예) /files
• 컨트롤러(controller), 컨트롤 URI
  • 문서, 컬렉션, 스투어로 해결하기 어려운 추가 프로세스 실행
  • 동사를 직접 사용
  • 예) /members/{id}/delete

상태 코드

클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능

• 1xx (informational) : 요청이 수신되어 처리중
• 2xx (Successful) : 요청 정상 처리
  • 201 : 요청 성공해서 새로운 리소스가 생성됨
  • 202 : 요청이 접속되었으나 처리가 완료되지 않았음
    • 배치 처리 같은 곳에서 사용
    • 예) 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리함
  • 204 : 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음
    • 예) 웹 문서 편집기에서 save 버튼
    • Save 버튼의 결과로 아무 내용이 없어도 된다
    • Save 버튼을 눌러도 같은 화면을 유지해야 한다.
    • 결과 내용이 없어도 204 메시지(2xx)만으로 성공을 인식할 수 있다.
• 3xx (Redirection) : 요청을 완료하려면 추가 행동이 필요
  • 영구 리다이렉션(301,308)
    • 리소스 URI가 영구적으로 이동
    • 원래의 URL를 사용X, 검색 엔진 등에서도 변경 인지
    • 301 Moved Permanently
      • 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)
    • 308 Permanent Redirect
      • 301과 기능은 같음
      • 리다이렉트시 요청 메서드와 본문 유지(처음 POST를 보내면 리다이렉트도)
  • 일시적인 리다이렉션(302,307,303)
    • 리소스의 URI가 일시적으로 변경
    • 따라서 검색 엔전 등에서 URL을 변경하면 안됨
    • 302 Found
      • 리다이렉트시 요청 메서드가 GET으로 변하고 본문이 제거될 수 있음
    • 307 Temporary Redirect
      • 302와 기능은 같음
      • 리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다.)
    • 303 See Other
      • 302와 기능은 같음
      • 리다이렉트시 요청 메서드가 GET으로 변경
  • 기타 리다이렉션
    • 300 Multiple Choices :안쓴다
    • 304 Not Modified
      • 캐시를 목적으로 사용
      • 클라이언트에게 리소스가 수정되지 않았음을 알려준다. 따라서 클라이언트는 로컬 PC에 저장된 캐시를 재사용한다.(캐시로 리다이렉트 한다.)
      • 304응답은 응답에 메시지 바디를 포함하면 안된다.(로컬 캐시를 사용해야하므로)
      • 조건부 GET, HEAD 요청시 사용
• 4xx (Client Error) : 클라이언트 오류, 잘못된 문법등으로 요청을 수행할 수 없음
  • 400 Bad Request
    • 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음
      • 요청 구문, 메시지 등등 오류
      • 클라이언트는 요청 내용을 다시 검토하고, 보내야함
      • 예) 요청 파라미터가 잘못도거나, API 스펙이 맞지 않을 때
  • 401 Unauthorized
    • 클라이언트가 해당 리소스에 대한 인증이 필요함
      • 인증 되지 않음
      • 401 오류 발생시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명
      • 참고
        • 인증 : 본인이 누구인지 확인, 로그인
        • 인가 : 권한부여(ADMIN 권한처럼 특정 리소스에 접근할 수 있는 권한, 인증이 있어야 인가가 있음)
        • 오류 메시지가 Unauthorized 이지만 인증 되지 않음
  • 403 Forbidden
    • 서버가 요청을 이해했지만 승인을 거부함
      • 주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우
      • 예) 어드민 등급이 아닌 사용자가 로그인은 했지만, 어드민 등급의 리소스에 접근하는 경우
  • 404 Not Found
    • 요청 리소스를 찾을 수 없음
      • 요청 리소스가 서버에 없음
      • 또는 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶을 때
• 5xx (Server Error) : 서버오류, 서버가 정상 요청을 처리하지 못함
  • 500 Internal Server Error
    • 서버 문제로 오류 발생, 애매하면 500 오류
      • 서버 내부 문제로 오류 발생
      • 애매하면 500 오류
  • 503 Service Unavailable
    • 서비스 이용 불가
      • 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음
      • Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수도 있음

쿠키

• Set-Cookie : 서버에서 클라이언트로 쿠키 전달(응답)
• Cookie : 클라이언트가 서버에서 받은 쿠키를 저장하고 , HTTP 요청시 서버로 전달
• 사용처
  • 사용자 로그인 세션 관리
  • 광고 정보 트래킹
• 쿠키 정보는 항상 서버에 전송됨
  • 네트워크 트래픽 추가 유발
  • 최소한의 정보만 사용(세션 id, 인증 토큰)
  • 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹스토리지 (localStorage, sessionStorage) 참고
• 주의 !
  • 보안에 민감함 데이터는 저장하면 안됨(주민번호, 신용카트 번호 등등)
• 생명주기
  • Set-Cookie : expires= Sat, 26~~~
    • 만료일이 되면 쿠키 삭제
  • Set-Cookie : max-age=3600(3600초)
    • 0이나 음수를 지정하면 쿠키 삭제
  • 세션 쿠키 : 만료 날짜를 생략하면 브루우저 종료시 까지만 유지
  • 영속 쿠키 : 만료 날짜를 입력하면 해당 날짜까지 유지
• 도메인
  • 명시 : 명시한 문서 기준 도메인 + 서브 도메인 포함
    • Domain = example.org를 지정해서 쿠키 생성
      • example.org는 물론이고 dev.example.org도 쿠키 접근
  • 생략 : 현재 문서 기준 도메인만 적용
    • example.org에서 쿠키를 생성하고 domain 지정을 생략
      • example.org에서만 쿠키 접근
      • Dev.example.org는 쿠키 미접근
• 보안
  • Secure
    • 쿠키는 http, https를 구분하지 않고 전송
    • Secure를 적용하면 https인 경우에만 전송
  • HttpOnly
    • Xss 공격 방지
    • 자바스크립트에서 접근 불가
    • HTTP 전송에만 사용
  • SameSite
    • XSRF 공격 방지
    • 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송

캐시 적용

• 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다
• 비싼 네트워크 사용량을 줄일 수 있다
• 브라우저 로딩 속도가 매우 빠르다
• 빠른 사용자 경험

검증 헤더와 조건부 요청

• 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면
• 304 Not Modified + 헤더 메타 정보만 응답(바디X)
• 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신
• 클라이언트는 캐시에 저장되어 있는 데이터 재활용
• 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드
• 매우 실용적인 해결책