배움을 기록으로

6. HTTP 상태코드

6.1. 상태코드

• 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
  
  • 1xx (Information): 요청이 수신되어 처리중
  • 2xx (Successful): 요청 정상 처리
  • 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요 (리다이렉션)
  • 4xx (Client Error): 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음
  • 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함

'HTTP 상태코드 값을 전부 외워야 할까?'

• 클라이언트는 상위 코드로 해석해서 처리
• 미래에 새로운 상태 코드가 추가되어도 클라이언트를 변경하지 않아도 됨
• 예)
  • 289 -> 2xx (요청이 성공 했구나~)
  • 455 -> 4xx (클라이언트에서 잘못 요청했구나~)
  • 598 -> 5xx (서버쪽에 오류가 있구나~)

'리다이렉션(Redirection)이란?'

• 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동 (리다이렉트)
• 흐름
  1. 요청 (/notice)
  2. 응답 (Location: /new-notice)
  3. Location URL로 자동 리다이렉트
  4. 요청 (/new-notice)
  5. 응답 (200 OK)
• 종류
  • 영구 리다이렉션 (특정 리소스의 URI가 영구적으로 이동)
    • 보통 URL 주소가 변경된 경우, 이전 URL로 들어오는 유입에 대해 변경된 주소로 리다이렉션하여 처리 
    • 예) /main -> /home
  • 일시 리다이렉션 (일시적인 변경)
    • 요청 처리 후, 다른 페이지로 이동시키는 경우로, 클라이언트의 중복 요청을 방지한다.
    • 클라이언트의 URL이 리다이렉트된 URL로 변경된다. (새로고침시 중복 요청 방지)
    • PRG: Post / Redirect / Get
    • 예) 주문요청 (Post) > 주문 완료페이지로 리다이렉션(Redirect) > 주문 완료페이지 이동 (Get)
            (주문 요청을 여러 번 하더라도, 주문완료 페이지만 GET으로 호출됨.)
  • 특수 리다이렉션
    • 결과 대신 클라이언트에 있는 캐시를 사용

[ 1xx (Informational)  ]

• 요청이 수신되어 처리중인 상태
• 거의 사용하지 않는다.
  
  

[ 2xx (Successful)  ]

• 클라이언트의 요청을 성공적으로 처리
• 종류
  • 200 OK (요청 성공)
  • 201 Created (요청 성공해서 새로운 리소스가 생성됨)
  • 202 Accepted (요청이 접수되었으나 처리가 완료되지 않았음)
    • 배치 처리 같은 곳에서 사용
    • 예) 배치 요청 접수 성공 후, 1시간 뒤에 배치 프로세스가 요청을 처리하는 경우
  • 204 No Content (서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음)
    • 저장 후에 아무 내용이 없어도 된다.
    • 보통 저장 후에 같은 화면을 유지해야 하는 경우 사용
    • 결과 내용이 없어도 204 메시지(2xx)만으로 성공을 인식할 수 있는 경우

[ 3xx (Redirection)  ]

• 요청을 완료하기 위해 유저 에이전트의 추가 조치 필요
• 종류
  • 300 Multiple Choices (안쓴다)
  • 301 Moved Permanently
    • 영구 리다이렉션
    • 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음
      (POST로 요청해도,  GET으로 리다이렉트)
  • 302 Found
    • 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음
      (원래 스펙은 메서드 유지지만, 통상적으로 GET으로 변경됨)
  • 303 See Other
    • 302와 기능은 같음
    • 리다이렉트시 요청 메서드가 GET으로 변경
  • 304 Not Modifield
    • 캐시 목적으로 사용
    • 리소스가 수정되지 않았음을 알려주고, 클라이언트에 저장된 캐시를 재사용하도록한다 (캐시로 리다이렉트)
    • 응답에 메시지 바디를 포함하면 안된다. (로컬 캐시를 사용해야 하므로)
    • 조건부 GET, HEAD 요청시 사용
  • 307 Temporary Redirect
    • 302와 기능은 같음
    • 리다이렉트시 요청 메서드와 본문 유지
  • 308 Permanent Redirect
    • 301과 기능은 같음 (영구 리다이렉션)
    • 리다이렉트시 요청 메서드와 동일하게 분문 유지 (POST로 요청했을때 POST로 리다이렉트)
      
      
      

'302, 307, 303 상태코드는 서로 비슷한데 뭘 써야할까?'

• 302, 307, 303
  • 302 Found: GET으로 변할 수 있음 (May)
  • 307 Temporary Redirect: 메서드가 변하면 안됨 (유지)
  • 303 See Other: 메서드가 GET으로 변경 (변경)
• 히스토리
  • 처음 302 스펙의 의도는 HTTP 메서드를 유지하는 것
  • 하지만 통상적으로 브라우저에서 GET으로 바꿔서 사용하였음
  • 그래서 기존에 영향을 안주면서 명확한 상태코드인 307, 303이 등장 (301 대용으로 308도 등장)
• 이미 많은 애플리케이션들이 302를 기본값으로 사용하므로 GET으로 변해도 302를 사용하여도 큰 문제 없음

[ 4xx (Client Error)  ]

• 클라이언트의 요청에 잘못된 문법 등으로 서버가 요청을 수행할 수 없음
• 클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에, 똑같이 재시도를 하면 실패함 (5xx와 차이점)
• 종류
  •  
  • 400 Bad Request (클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음)
    • 요청 구분, 메시지 등 오류
    • 클라이언트는 요청 내용을 검토해서 다시 보내야함
    • 예) 요청 파라미터가 잘못되거나 API 스펙이 맞지 않을때
           (필수 요청 파라미터 누락, 미성년자 주류 구매, 로그인시 비밀번호 틀린 경우)
  • 401 Unauthorized (클라이언트가 해당 리소스에 대한 인증이 필요함)
    • 해당 리소스에 유효한 인증 자격 증명이 없기 때문에 요청이 적용되지 않은 경우
    • 401 오류 발생시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명
    • 예) 사용자가 로그인되지 않은 경우
  • 403 Forbidden (서버가 요청을 이해했지만 승인을 거부함)
    • 주로 인증 자격 증명은 있지만(인증), 접근 권한이 불충분한 경우(인가)
    • 401 오류 발생시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명
    • 예) 일반 사용자가 로그인하여(인증), 관리자 등급의 리소스에 접근하는 경우(인가)
  • 404 Not Found
    • 요청 리소스를 찾을 수 없음
    • 클라이언트가 권한이 부족한 리소스에 접근할 때(403 케이스), 해당 리소스를 숨기고 싶을때 사용하기도 함
    • 예) 잘못된 URL 요청 (www.naverrr.com)

[ 5xx (Server Error)  ]

• 서버 오류
• 서버에 문제가 있기 때문에 재시도하면 성공할 수도 있음 (복구가 되거나 등, 400에러와 차이점)
• 종류
  • 500 Internal Server Error (서버 문제로 오류 발생, 애매하면 500 오류)
    • 서버 내부 문제로 오류 발생
    • 예) 서버 사용량 폭주로 서비스가 일시 중단, 문법적 오류 (NullPointException), DB 접속 실패 등
  • 503 Service Unavailable (서비스 이용 불가)
    • 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음
    • Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수도 있음

References

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

https://developer.mozilla.org/ko/docs/Web/HTTP/Status/401

5. HTTP 메서드 활용

5.1. 클라이언트에서 서버로 데이터 전송

'데이터 전달 방식은 크게 2가지!'

• 쿼리 파라미터를 통한 데이터 전송
  • GET
  • 주로 정렬 필터(검색어)
• 메시지 바디를 통한 데이터 전송
  • POST, PUT, PATCH
  • 회원가입, 상품주문, 리소스 등록, 리소스 변경

'데이터 전송 케이스는 크게 4가지!'

• 정적 데이터 조회
  • 이미지, 정적 텍스트 문서
  • GET 메서드 사용
  • 쿼리 파라미터 없이 리소스 경로로 단순하게 조회
    
    
• 동적 데이터 조회
  • 주로 검색, 게시판 목록에서 정렬 필터(검색어)
  • 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 조건에 주로 사용
  • GET 메서드 사용
  • GET은 쿼리 파라미터를 사용하여 데이터 전달
  • 예) https://www.google.com/search?q=인프런
    
    
• HTML, Form을 통한 데이터 전송
  • HTML Form submit시 POST 전송
    • 예) 회원가입, 상품주문, 데이터 변경
  • Content-Type: application/x-www-urlencoded 사용
    • form의 내용을 메시지 바디를 통해서 전송 (key=value, 쿼리 파라미터 형식)
    • 전송 데이터를 urlencoding 처리 (서버에서 decoding이 필요할 수 있음)
      • 예) abc김 -> abs%EA%B9*80 
  • HTML Form은 GET 전송도 가능
  • Content-Type: multipart/form-data
    • 파일 업로드 같은 바이너리 데이터 전송시 사용
    • 다른 종류의 여러 파일과 폼의 내용 함께 전송 가능 (그래서 이름이 multipart)
  • 참고: HTML Form 전송은 GET, POST만 지원
    
    
• HTTP API를 통한 데이터 전송
  • 예) 회원가입, 상품주문, 데이터 변경
  • 서버 to 서버
    • 백엔드 시스템 통신
  • 앱 클라이언트
    • 아이폰, 안드로이드
  • 웹 클라이언트(Ajax)
    • HTML에서 Form 전송 대신 자바 스크립트를 통한 통신에 사용 (AJAX)
    • 예) React, VueJs 같은 웹 클라이언트와 API 통신
  • POST, PUT, PATCH: 메시지 바디를 통해 데이터 전송
  • GET: 조회, 쿼리 파라미터로 데이터 전달
  • Content-Type: application/json을 주로 사용 (사실상 표준)
    • TEXT, XML, JSON 등등

5.2. HTTP API 설계 예시

'POST 기반 등록'

• 클라이언트는 등록될 리소스의 URI를 모른다.
  • 회원등록 /members -> POST
  • POST /members
• 서버가 새로 등록된 리소스 URI를 생성해준다.
  • HTTP/1.1 201 Created
    Location: /members/100
  • 예) 회원등록시, 회원번호는 API단에서 생성한다.
         (고객이 가입정보에 회원번호를 입력하지 않는다)
• 컬렉션 (Collection)
  • 서버가 관리하는 리소스 디렉토리
  • 서버가 리소스의 URI를 생성하고 관리
  • 여기서 컬렉션은 /members

[ 예시 ]

• 회원 목록 /members -> GET
• 회원 등록 /members -> POST
• 회원 조회 /members/{id} -> GET
• 회원 수정 /members/{id} -> PATCH, PUT, POST
  • 보통은 PATCH를 사용하는 것을 추천 (수정하려는 데이터만 넘겨서 수정 가능)
  • PUT은 완전히 덮어써도 괜찮은 경우
    • 예) 게시판의 게시글을 수정하는 경우
• 회원 삭제 /members/{id} -> DELETE

'PUT 기반 등록'

• 클라이언트가 리소스 URI를 알고 있어야 한다.
  • 파일 등록 /files/{filename} -> PUT
  • PUT /files/start.jpg
  • 예) 파일 등록 (클라이언트가 파일명을 알고있다)
• 클라이언트가 직접 리소스의 URI를 지정한다.
• 스토어 (Store)
  • 클라이언트가 관리하는 리소스 저장소
  • 클라이언트가 리소스의 URI를 알고 관리
  • 여기서 스토어는 /files
  • 예) 정적 컨텐츠 관리, 원격 파일 관리

[ 예시 ]

• 파일 목록 /files-> GET
• 파일 조회 /files/{filename} -> GET
• 파일 등록 /files/{filename} -> PUT
• 파일 삭제 /files/{filename} -> DELETE
• 파일 대량 등록 /files -> POST
  •  

'HTML FORM 사용'

• 순수 HTML + HTML form 사용
• HTML FORM은 GET, POST만 지원
• 컨트롤러(controller), 컨트롤 URI
  • GET, POST만 지원하므로 제약이 있음
  • 이런 제약을 해결하기 위해 동사로 된 리소스 경로 사용
  • POST의 /new, /edit, /delete가 컨트롤 URI
  • HTTP 메서드로 해결하기 애매한 경우 사용 (HTTP API 포함)
    

[ 예시 ]

• 회원 목록 /members -> GET
• 회원 등록 폼 /members/new -> GET
• 회원 등록 /members/new, /members -> POST
• 회원 조회 /members/{id} -> GET
• 회원 수정 폼 /members/{id}/edit -> GET
• 회원 수정 /members/{id}/edit, /members/{id} -> POST
• 회원 삭제 /members/{id}/delete -> POST

References

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

https://restfulapi.net/resource-naming/

4. HTTP 메서드

4.1. HTTP API를 만들어보자

'회원 정보 관리 API의 URI를 설계해보자'

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

'이것은 좋은 URI 설계일까?'

• URI 설계시 가장 중요한 것은 리소스 식별이다
• 리소스의 의미는 뭘까?
  • 회원을 등록하고 수정하고 조회하는게 리소스가 아니다!
  • 예) 미네랄을 캐라 -> 미네랄이 리소스
  • 회원이라는 개념 자체가 바로 리소스다.
• 리소스는 어떻게 식별하는게 좋을까?
  • 회원을 등록하고 수정하고 조회하는 것을 모두 배제
  • 회원이라는 리소스만 식별하면 된다. -> 회원 리소스를 URI에 매핑
• URI 계층 구조를 활용한다.
  • 슬래시 구분자(/)는 계층 관계를 나타내는데 사용한다.
  • 예) http://test.example.com/members/{id}

'리소스 식별, URI 계층 구조를 활용하여 URI 설계를 다시 해보자!'

• 회원 목록 조회 /members
• 회원 조회 /members/{id}
• 회원 등록 /members/{id}
• 회원 수정 /members/{id}
• 회원 삭제 /members/{id}
  
• 참고: 계층 구조상 상위를 컬렉션으로 보고 복수 단어 사용 권장(member -> members)
  
  
  
  

'같은 리소스를 사용하는 경우, 어떻게 구분해야 할까?'

• 리소스와 해당 리소스를 대상으로 하는 행위를 분리
  • 리소스: 회원
  • 행위: 조회, 등록, 삭제, 변경
• 리소스는 명사, 행위는 동사 (미네랄을 캐라)
• 행위(메서드)는 HTTP 메서드로 구분한다.

[ HTTP 메서드 ]

• GET: 리소스 조회
  • 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
  • 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음
• POST: 요청 데이터 처리, 주로 등록에 사용
  • 메시지 바디를 통해 서버로 요청 데이터 전달
  • 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용
  • 애매한 곳은 POST를 사용하면 된다 (다른 메서드로 처리하기 애매한 경우)
• PUT: 리소스를 대체, 해당 리소스가 없으면 생성
  • POST와 차이점: 클라이언트가 리소스 위치를 알고 URI 지정
    • 예) /members/{id}
  • PUT은 기존 리소스를 삭제하고 완전히 대체하기 때문에 중요한 데이터는 PUT을 사용하면 안된다.
    (중요한 데이터를 부분 수정하려면 PATCH를 사용한다)
• PATCH: 리소스 부분 변경
• DELETE: 리소스 삭제
  
  

[ HTTP 메서드 속성 ]

• 안전 (Safe Methods)
  • 호출해도 리소스를 변경하지 않는다.
  • GET, HEAD 메서드가 안전 메서드이다.
• 멱등 (Idenmpotent Methods)
  • 한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다. (외부 요인으로 중간에 리소스가 변경되는 것은 고려 X)
  • 멱등 메서드
    • GET: 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다.
    • PUT: 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.
    • DELETE: 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.
    • POST: 멱등이 아니다! 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.
      
    • PATCH: 멱등으로 설계할 수도 있지만, 멱등이 아니게 설계할 수도 있다. (참고)
      
  • 활용
    • 자동 복구 메커니즘
    • 서버가 TIMEOUT 등으로 정상 응답을 못주었을 때, 클라이언트가 같은 요청을 다시 해도 되는가? 판단 근거
      
• 캐시가능 (Cacheable Methods)
  
  • 응답 결과 리소스를 캐시해서 사용해도 되는가?
  • GET, HEAD, POST, PATCH 메서드가 캐시 가능
  • 실제로는 GET, HEAD 정도만 캐시로 사용
    • POST, PATCH는 본문 내용까지 캐시 키로 교려해야 하는데, 구현이 쉽지 않음
      
      

References

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

3. HTTP 기본

3.1. 모든 것이 HTTP

'HTTP 메시지에 모든 것을 전송'

• HTML, TEXT
• IMAGE, 음성, 영상, 파일 등
• JSON, XML
• 거의 모든 형태의 데이터 전송 가능
• 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용
• HTTP/1.1이 현재 가장 많이 사용하는 버전이며, 그 이후 버전은 성능 개선 위주

[ 기반 프로토콜 ]

• TCP : HTTP/1.1, HTTP/2
• UDP: HTTP/3
• 현재 HTTP/1.1 주로 사용 (HTTP/2, HTTP/3 도 점점 증가)

[ HTTP 특징 ]

• 클라이언트 서버 구조
• 무상태 프로토콜(스테이트리스), 비연결성
• HTTP 메시지
• 단순함, 확장 가능
  
  

3.2. 클라이언트 서버 구조

'Request Response 구조'

• Request Response 구조 (클라이언트와 서버를 개념적으로 분리)
• 클라이언트는 UI와 사용성, 서버는 복잡한 비지니스 로직 및 데이터를 전담 (역할 분리 > 독립적 진화 가능)
• 클라이언트는 서버에 요청을 보내고, 응답을 대기
• 서버가 요청에 대한 결과를 만들어서 응답

3.3. Stateful, Stateless

'HTTP는 무상태 프로토콜을 지향한다 (Stateless)'

• 서버가 클라이언트의 상태를 보존하지 않는다.
• 장점: 서버 확장성 높음 (스케일 아웃 > 수평 확장 유리)
• 단점: 클라이언트가 추가 데이터 전송 (필요한 데이터를 모두 넘겨야 하기 때문)
• 실무 한계
  • 모든 것을 무상태로 설계 할 수 있는 경우도 있고 없는 경우도 있다.
    • 상태 유지: 로그인이 필요한 화면
      • 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지
      • 일반적으로 브라우저 쿠키와 서버 세션 등을 사용해서 상태 유지 (무상태에서 로그인 상태 유지하는 방법)
      • 상태 유지는 최소한만 사용
    • 무상태: 로그인이 필요 없는 단순한 서비스 소개 화면
• 결론: 애플리케이션 설계시에는 최대한 무상태로 설계하고, 상태 유지는 최소한만 사용한다.

[ Stateful, Stateless ]

• 상태 유지: 중간에 다른 서버로 바뀌면 안된다.
                  (다른 서버로 바뀔 때 상태 정보를 다른 서버에게 미리 알려줘야 한다.)
  • 중간에 서버가 장애나면? 클라이언트는 처음부터 다시 요청을 해야한다.
    
    
• 무상태: 클라이언트의 상태를 보존하지 않으므로, 중간에 다른 서버로 응답할 수 있다.
  
  • 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.
  • 무상태는 응답 서버를 쉽게 바꿀 수 있다.
  • 중간에 서버1이 장애나면? 서버2가 응답하면 된다.
    
    

3.4. 비 연결성 (connectionless)

'비 연결성이란?'

• 연결을 유지하지 않는 모델이다.
• HTTP는 일반적으로 초 단위의 이하의 빠른 속도로 응답 (요청할 때마다 연결하여 사용 가능, 요청이 끝난 후에는 연결 종료)
• 1시간 동안 수천명이 서비를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작다.
  • 예) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다.
• 서버의 자원을 매우 효율적으로 사용할 수 있다. (최소한의 자원 사용하여 서버 유지 가능)
• 한계와 극복
  • TCP/IP 연결을 새로 맺어야 함 (3 way handshake 시간 추가)
  • 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 JS,CSS, 추가 이미지 등 수 많은 자원이 함께 다운로드
  • 지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결
    (연결만 상태 유지하여, 매 요청시 연결을 새로 하지 않도록)
  • HTTP/2, HTTP/3에서 더 많은 최적화
• 대용량 트래픽 설계시에는 Stateless를 꼭 기억하자
  • 같은 시간에 발생하는 대용량 트래픽
  • 이벤트가 생길때 사용자가 급증하는 경우
  • 팁: 정적 페이지를 하나 보게 한 다음, 이벤트 페이지로 들어가게 만드는 방법 (최대한 동시 요청을 적게)
    
    

3.5. HTTP 메시지

'HTTP 메시지 구조'

[ 예시 ]

• 요청 메시지

• 응답 메시지

3.6. HTTP 정리

'지금은 HTTP 시대'

• HTTP 메시지에 모든 것을 전송
• HTTP 역사 HTTP/1.1을 기준으로 학습
• 클라이언트 서버 구조
• 무상태 프로토콜(스테이스리스)
• HTTP 메시지
• 단순함, 확장 가능
• 크게 성공하는 표준 기술은 단순하지만 확장 가능한 기술 (HTTP 메시지도 매우 단순)
  
  

References

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

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

2.1. URL (Uniform Resource Identifier)

'URI? URL? URN?'

• URI와 URL이 혼동되기 쉽다. 결론부터 말하자면 URI는 URL와 URN의 상위 개념이다.

[ URI 단어 뜻 ]

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

[ URL, URN ]

• URL - Locator: 리소스가 있는 위치를 지정
• URN - Name: 리소스에 이름을 부여
• 위치는 변할 수 있지만, 이름은 변하지 않는다.
• 통상적으로 URI와 URL을 같은 의미로 사용하기도 한다.

[ URL 문법 ]

https://www.google.com:443/search?q=hello&hl=ko 

• 프로토콜 (https)
• 호스트명 (www.google.com)
• 포트 번호 (443, 생략가능)
• 패스 (/search)
• 쿼리 파라미터 (q=hello&hl=ko)

2.2. 웹 브라우저 요청 흐름

'브라우저에 검색창에 'www.google.com'을 입력하면 일어나는일'

1.  'www.google.com'에 대한 DNS 서버를 조회
   • IP와 PORT 정보를 얻는다
   • 캐싱된 DNS 기록을 체크
2.  웹 브라우저가 HTTP 요청 메시지를 생성
3.  SOKET 라이브러리를 통해 OS 단으로 HTTP 메시지를 전달한다.
   • TCP/IP 연결 (구글 서버와 연결 상태 확인)
   • 데이터 전달 (OS 단으로)
4.  TCP/IP 패킷 생성, HTTP 메시지 포함
5.  웹 브라우저에서 요청 패킷을 구글 서버에 전달 / 도착
6.  구글 서버에서 HTTP 요청 메시지에 대한 HTTP 응답 메시지 생성
7.  구글 서버에서 응답 패킷을 웹 브라우저에 전달 / 도착
8.  받은 응답 패킷을 기준으로 웹 브라우저에 HTML 렌더링

References

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

실무에서 백엔드 개발을 진행하면서, 네트워크/인프라 등 배경지식이 부족하다고 느껴져서

네트워크 기초에 대한 부분을 공부하기로 하였다.

실무 개발에 필요한 HTTP의 전체 흐름 이해하기 위한 포스팅이며

'모든 개발자를 위한 HTTP 웹 기본 지식' 강의를 학습한 내용을 정리할 생각이다.

1.인터넷 네트워크

1.1. 인터넷 통신

'인터넷 상에서 컴퓨터 둘은 어떻게 통신할까?'

•  직접 연결 (클라이언트와 서버, 둘 사이가 가까운 경우), 하지만 한계가 있다. 사내망 같은 사설망에서만 사용
•  인터넷망 이용(거리가 멀어도 통신 가능)하며, 인터넷망은 IP를 사용하여 통신한다.

1.2. IP(인터넷 프로토콜)

'복잡한 인터넷망은 어떻게 통신을 할까?'

•  클라이언트와 서버에 IP 주소를 부여 (출발지와 목적지에 대한 주소)
•  IP 주소에 데이터 전달
•  패킷이라는 통신 단위로 데이터 전달

[ IP ]

•  인터넷 프로토콜 (Internet Protocol)의 약자
•  네트워크상에서 컴퓨터(노드)를 식별하기 위한 위치 주소
•  한계 및 문제점
  • 비연결성: 패킷을 받을 대상이 없거나, 서비스 불능 상태여도 패킷 전송
  • 비신뢰성: 중간에 패킷이 오거나, 순서대로 안 오는 경우 신뢰할 수 없다.
  • 프로그램 구분: 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 2개 이상인 경우 구별 불가
• 해당 한계들을 극복하고자, TCP/UDP가 등장하기 시작했다.

[ IP 패킷 ]

• 정보 : 출발지 IP, 목적지 IP, 기타
• 출발지 IP에서 목적지 IP로 요청을 클라이언트 패킷에 담아 전달한다.
• 목적지 IP에서 요청에 대한 응답을 서버 패킷에 담아 전달한다.

1.3. TCP/UDP

'IP만으로 통신할 때의 한계나 문제점을 어떻게 해결해야 할까?'

• 비연결성 : 통신 전에 클라이언트와 서버의 연결 상태 및 데이터 전달 보증 확인
• 비신뢰성 : 패킷에 데이터의 순서 정보를 함께 보낸다
• 프로그램 구분 : 프로그램별 구분 값(PORT)을 이용

[ 인터넷 프로토콜 스택의 4계층 ]

• 애플리케이션 계층 - HTTP, FTP
• 전송계층 - TCP, UDP
• 인터넷 계층 - IP
• 네트워크 인터페이스 계층

[ TCP (Transmission Control Protocl) 특징 ]

• 연결지향 - TCP 3 way handshake (가상 연결, 논리적 연결)
• 데이터 전달 보증
• 순서 보장
• 신뢰할 수 있는 프로토콜
• 현재는 대부분 TCP 사용

[ TCP 3 way handshake ]

1. SYN : 클라이언트 > 서버 (접속 요청)
2. SYN+ACK : 서버 > 클라이언트 (연결 요청 수락)
3. ACK: 클라이언트 > 서버 (연결 요청 수락에 대한 응답)
4. 데이터 전송 (참고: 요즘에는 최적화로 인해 ACK와 함께 데이터 전송도 가능)

[ UDP (User Datagram Protocol) ]

• 연결지향 X
• 데이터 전달 보증 X
• 순서 보장 X
• IP와 거의 같다. +PORT +체크섬 정도만 추가
• 애플리케이션에서 추가 작업 필요

UDP는 왜 쓰는걸까?

• 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름
• TCP에 비해 보안적으로 덜 안전하지만, 많은 양의 데이터를 빠르게 전달 가능 (영상 스트리밍이나 음성에 활용)
• 최근 인터넷이 거의 TCP 기반으로 되어있기 때문에, TCP를 수정하기가 어려움 
• 그래서 최적화를 위한 수정 개발시에는 UDP를 활용, 최근에는 UDP가 뜨고 있다고함 (ex: HTTP 프로토콜)

1.4. PORT

'한 번에 둘 이상 연결해야 한다면 어떻게 해야할까?'

[ PORT 특징 ]

• 같은 IP 내에서 프로그램(프로세스)를 구분
• 0 ~ 65535 할당 가능
• 0 ~ 1023 : 잘 알려진 포트, 사용하지 않는 것이 좋음
  • FTP - 20, 21
  • TELNET - 23
  • HTTP - 80
  • HTTPS - 443

1.5. DNS

'IP는 기억하기 어렵고, 변경될 수 있다.'

•  도메인 이름 시스템(DNS)은 사람이 읽을 수 있는 도메인 이름(예: www.amazon.com)을 머신이 읽을 수 있는 IP 주소(예: 192.0.2.44)로 변환
  
  

References

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

전체적인 흐름

1) 브라우저에 검색창에 'www.google.com'을 입력 후. 엔터를 친다.

• 특정 웹사이트에 접속하기 위해서는 'www.google.com' 과 같은 도메인(Domain)이 아닌 '127.0.0.1'과 같은 IP 주소가 필요하다.
• 하지만 IP 주소는 외우기가 힘들고, 가독성이 떨어지기 때문에 도메인 명으로 웹페이지에 접속할 수 있도록 DNS 서버를 이용한다.
• DNS는 Doman Name System의 약자로 URL의 이름과 IP주소를 저장하고 있는 데이터베이스이다. (like 전화번호부)

2) 브라우저는 캐싱된 DNS 기록을 체크한다.

• 브라우저는 4가지 캐시를 확인한다. (Browser캐시 >OS 캐시 (systemcall) > router 캐시 > ISP 캐시
• 캐시는 네트워크 트랙픽 조절과 데이터 전송 시간을 줄여준다.
• ISP는 인터넷 서비스 공급자의 약자이다. ex) SK, LG, KT 등

3) 요청한 URL이 캐시에 없으면, ISP의 DNS 서버에서 다른 DNS 서버를 DNS Query를 통해 검색하여 IP 주소를 찾는다.

• 캐시에 요청한 URL의 IP 정보가 없으면, ISP는 DNS 서버들을 검색해 해당 도메인의 IP 주소를 검색한다.
• 해당 검색기법을 recursive search라 부르며, IP 주소를 찾을 때까지, DNS 서버에서 다른 DNS 서버를 오가면서 반복 검색을 진행한다.

4) 브라우저가 서버와 TCP connection을 한다.

• 브라우저가 IP 주소를 얻게되면 서버와 http connection을 통해 서버와 연결을 한다.
• HTTP 연결의 경우 대표적인 인터넷 프로토콜인 TCP를 일반적으로 사용한다.
• TCP/IP three-way handshake라는 프로세스를 통해서 클라이언트와 서버간 connection이 이뤄지게 된다. 

5) Browser가 웹서버에 HTTP 요청을 한다.

• TCP 연결이 되면, 데이터 전송을 하면된다.
• 클라이언트는 GET 요청을 통해 서버에서 'www.google.com' 웹페이지를 요구한다.
• 요청에 따라 부가적인 정보들이 함께 전송되는데 개발자 도구의 network에서 자세한 내용을 확인할 수 있다.

6) 서버가 요청을 처리하고, response를 생성한다.

• 서버가 가지고 있는 웹서버에서 브라우저로부터 온 요청을 읽고 response를 생성한다.
• response를 특정한 포맷(JSON, XML, HTML)으로 작성한다.

7) 서버가 HTTP Response를 보낸다.

• 서버의 response에는 요청한 웹페이지, 상태코드, 쿠키, 개인정보 등이 포함되어있다.

8) 브라우저가 HTML content를 보여준다.

• 브라우저는 html content를 단계적으로 렌더링 하여 노출한다.
• 해당 contents 들은 브라우저에 의해 캐싱되어 나중에 해당 페이지 재방문시 서버에 재요청하지 않도록 한다.
• 그 이후, 'www.google.com' 웹 페이지가 노출된다.

전체적인 흐름은 이해가 되는데 세부적인 내용은 이해가 가지 않는다. 네트워크 기초 공부를 조금 더 해야할 거 같다..

* 참고: https://devjin-blog.com/what-happen-browser-search/

* 본문 원문: What happens when you type an URL in the browser and press enter? 

 * 기본 인터넷 통신 지식

 1) IP (인터넷 프로토콜)

   - 지정한 IP 주소(IP Address)에 데이터 전달

   - 패킷(Packet) 이라는 통신 단위로 데이터 전달

   * IP 프로토콜의 한계

      - 비연결성 : 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송

      - 비신뢰성 : 중간에 패킷이 사라지는 경우, 패q킷이 순서대로 안오는 경우

      - 프로그램 구분 : 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상인 경우

      > IP 프로토콜 한계 보완 -> TCP, UDP

 - TCP, UDP

 - PORT

 - DNS