HTTP 웹 기본 지식

인터넷 통신
클라이언트 - 인터넷 - 서버

IP(인터넷 프로토콜)
- 클라이언트 패킷 전달 - 전송 데이터(출발지 ip, 목적지 ip , 기타..)
- 서버 패킷 전달 - 전송 데이터(출발지 ip, 목적지 ip , 기타..)

IP 프로토콜 문제
비연결성
- 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송
비신뢰성
- 중간에 패킷이 사라지거나 순서대로 안오면? 해결이 안됨.
프로그램 구분
- 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이면? → 추후 포트에서 설명.

IP(인터넷 프로토콜) 문제를 해결하기 위한 방법으로 TCP 프로토콜이 나옴

TCP : 전송 제어 프로토콜
- 연결지향 (연결이 되어 있는지 확인.)
    - 3 way handshake (1. SYN 2. SYN+ACK 3.ACK)
- 데이터 전달 보증
- 순서 보장
- 신뢰할 수 있는 프로토콜
- 현재는 대부분 TCP 사용

UDP : 사용자 데이터그램 프로토콜
- 하얀 도화지에 비유(기능이 거의 없음)
 - 정리
- IP와 거의 같다 + 포트 + 체크섬 정도만 추가
- 애플리케이션에서 추가 작업이 필요
- 3 way handshake 를 하지 않으므로 TCP보다 빠르다.

포트 - 같은IP내에서 프로세스 구분 

DNS ( 도메인 명을 IP 주소로 변환 ) 

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

URL분석
https://www.google.com:443/search?q=hello&hl=ko
- 프로토콜
- 호스트명
- 포트번호
- path - 계층적 설계
- query
    - key=value 형태
    - ?로 시작, &로 추가 가능
    - query parameter , query string등으로 불림.

HTTP
- 모든 것이 HTTP
    - 서버 통신 (JSON, XML - API )
    - 이미지, 음성, 영상, 파일

- 클라이언트 서버 구조
    - Request , Response 구조
    - 클라이언트는 서버에 요청을 보내고 응답을 대기
    - 서버가 요청에 대한 결과를 만들어서 응답

- 무상태 프로토콜(Stateless)
    - 스케일 아웃 - 수평 확장에 유리하다.

- 스테이스리스를 기억하자
    - 서버 개발자들이 어려워하는 업무
    - 정말 같은 시간에 딱 맞춰 발생하는 대용량 트래픽
    - → 선착순 이벤트 등등..

http 메시지 구조
start-line
header
empty line
message body

HTTP 헤더의 용도
- 메시지 바다의 내용
- 인증, 요청 클라이언트의 정보
- 서버 애플리케이션 정보
- 캐시 관리 정보

HTTP API를 만들어보자
- 리소스 선별이 가장 중요하다!
    - 리소스란?
    - 미네랄을 캐라 → 미네랄이 리소스
    - 회원 조회 : 회원이라는 개념 자체가 리소스
- 리소스와 행위를 분리

HTTP API 데이터 전송
- 서버 to 서버
    - 백엔드 시스템 통신
- 웹 클라이언트
    - HTML에서 Form 전송 대신 자바스크립트를 통한 통신에 사용(AJAX)
    - - 리엑트, 뷰 같은 웹 클라이언트와 API 통신
- Context-Type : 주로 json을 사용

상태 코드 

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

- 1xx : 요청이 수신되어 처리중 -> 거의 사용하지 않으므로 생략.
- 2xx : 요청 정상 처리
- 3xx : 요청을 완료하려면 추가 행동이 필요
    - 웹 브라우저는 3xx 응답의 결과가 Location 헤더가 있으면, Location 위치로 자동 이동(리다이렉트)
    일시적 리다이렉션 (실무에서 많이 씀) 
    302 Found : 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음 -> 현실적으로 많이 사용함.
    307 Temporary Redirect : 리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다.)
    303 See Other : 리다이렉트시 요청 메서드가 GET으로 변경
    
    일시적 리다이렉션 - 예시
    POST로 주문 후에 웹 브라우저를 새로고침하면? 
    -> 중복주문이 될 수 있다.
    중복주문을 방지하려면?
    PRG: POST/Redirect/GET를 기억하자! (물론, 서버쪽에서 막는것도 중요하다!)
    POST로 주문후에 새로고침으로 인한 중복 주문 방지
    POST로 주문후에 주문 결과 화면을 GET 메서드로 리다이렉트
    새로고침을 해도 결과 화면을 GET으로 조회
    중복 주문 대신에 결과 화면만 GET으로 요청!  
    
    기타 리다이렉션
    304 Not Modified : 많이 쓰임
    클라이언트에게 리소스가 수정되지 않았음을 알려준다.
    -> 클라이언트는 로컬PC에 저장된 캐시를 재사용한다.
    
- 4xx : 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음 (Client Error)
    - 오류의 원인을 클라이언트에 있음.
    - 중요! 클라이언트가 이미 잘못된 요청, 똑같은 재시도 - 실패
    - 요청 파라미터가 잘못되거나, API 스펙이 맞지 않을 때 -> BE에서 스펙이 맞지 않으면 바로 튕겨야 함!!

- 5xx : 서버 오류, 서버가 정상 요청을 처리하지 못함 (Server Error)
    - 서버에 문제가 있기 때문에 재시도 하면 성공할 수도 있음(복구 등..)
    503 Service Unavailable 서비스 이용 불가 : 서버 일시적인 과부화.
    
    비즈니스 상 예외 케이스일 경우 - 정상적인 프로세스이므로 500에러를 내면 안된다.