인터넷 통신

• 컴퓨터들은 어떻게 통신을 하지?

• 어떤 규칙으로 서로 데이터가 안전하게 도착할 수 있을까?

• 예를 들어, 한국에 있는 당신이 미국에 있는 친구에게 "Hello, world!"라는 메시지를 인터넷으로 보내면 이 메시지는 먼저 소스 컴퓨터에서 출발해 인터넷이라는 거대한 네트워크로 들어간다.

• 인터넷은 해저 케이블이나 인공위성과 같은 다양한 방법으로 연결된 수많은 컴퓨터와 서버로 이루어져 있고 메시지는 이 네트워크를 통해 여러 중간 지점을 거치면서 최종적으로 미국에 있는 친구의 컴퓨터에 도착한다. (예시)

• 이 과정에서 중요한 역할이 바로 IP

• 어떻게 인터넷 정보를 주고받을지의 규칙

IP (Internet Protocol)

• 주소의 개념

• Packet이라는 통신 단위로 데이터 전달

• 서로의 주소를 알고 데이터 (메세지를 보낼때)

• 패킷이라는 규칙으로 보내야됨 !

• ip 프로토콜에 의해 서버들이 따르고 있는 규약.

• 내가 보낸 패킷을 서로 노드들끼리 출발지 목적지 이해하면서 주소까지 도착.

• 인터넷 상의 각 노드(중간 지점)들은 이 주소를 보고 패킷을 올바른 방향으로 전달

• 우체국이 우편번호와 주소를 보고 편지를 정확한 목적지로 배달하는거라 생각하자.

• 서버도 마찬가지로 새로운 메세지 만들어서 동일하게 보낸다.

IP 프로토콜의 한계

• 너 메세지 받을수 있는상태야? 모른다.

비연결성

• 패킷을 받을 대상이 없거나 서비스 불능이어도 그냥 전송!
• 그냥 보낸다 상태가 어떠한들 간에

• 중간에 보내다 서버가 꺼져도..

비신뢰성

• 여러개로 분할해서 보내도 순서를 보장하지 않음

• 음.. ip란 단순히 편지를 만드는 규격 으로 이해하면 될거같다

• 이 편지를 안전하게 보내듯 순서대로 보내든

• 다른놈이 알아서해!

왜이렇게 만들어졌지.

• IP 프로토콜이 단순하고 범용적으로 설계된 이유를 좀 더 쉽게 설명하자면, 전 세계 어디서든 잘 작동하도록 만들기 위해서

• 다양한 기술 장비 수많은 네트워크가 연결된 거대한 네트워크로 구성된 인터넷

• 이런 환경에서 모두 호환되고 잘장독하기 위해 서 이렇게 설계? 간단하고 범용성 있게

TCP/UDP

• 위 문제를 해결해주는 TCP 프로 토콜
• 그림은 각 계층을 이동할 때마다 헤더가 붙는다.

TCP/IP 패킷 정보

• 출발지 PORT , 목적지 PORT 여러가지 들어 있음..
• IP 프로토콜에서 해결이 안된 순서 제어 문제를 해결해 줌.

TCP(Transmission Control Protocol : 전송 제어 프로토콜)의 특징

특징

• 연결 지향 , TCP 3 WAY HANDSHAKE(가상연결)
  ( . 이 프로세스는 안정적인 연결을 확립하고, 데이터 전송을 시작하기 전에 두 장치(클라이언트와 서버)가 서로 통신할 준비가 되었는지 확인하는 데 사용)

• 데이터 전달 보증
• 순서 보장
• 신뢰 할수 있는 프로토콜
• 대부분 TCP 사용

• TCP(Transmission Control Protocol)는 인터넷 상에서 데이터를 안정적으로, 순서대로, 누락 없이 전송하기 위해 설계된 핵심 통신 규약

• 데이터를 패킷이라고 하는 작은 조각들로 나누어 전송하고, 이 패킷들이 목적지에 도착했는지 확인합니다. 만약 중간에 패킷이 손실되거나 오류가 발생한다면, TCP는 해당 패킷을 다시 전송하도록 요청

1. 연결설정 : 전송전 송신자 수신자 사이 가상 연결 설정

• 양쪽은 데이터를 주고받을 준비가 되었음 확인

2. 데이터 전송: 패킷 나누어 전송, 각 패킷은 고유번호 마킹 수신자가 올바른 순서로 재조립

3. 오류 검사 및 재전송 , 수신자는 모두 패킷을 받았나?
   오류없이 받았나 확인

4. 연결 종료 : 모든 데이터가 성공적으로 전송되면 종료

예시?

• 택배를 보내기전 택배회사와 수신자사이 계약

• 택배회사는 여러개 상자(패킷) 물건 나누어 담고 순서대로 번호 매겨서 전송, 목적지에 모두 전달되야 성공이라고 간주

• 오류 검사 및 재전송: 받는 사람은 모든상자가 도착했는지 확인?

• 연결 종료.. 등

+ 3 handShake

• 전화걸기(SYN) : 친구에게 전화걸어 통화 준비됨?

• 전화받기(SYN + ACK) : 친구: 전화받고 응 나준비됫어 너도?

• 확인하기 (ACK) : 응 나도 준비됬음, 시작하자 의미!

UDP(User Datagram Protocol : 사용자 데이터그램 프로토콜)의 특징

-기능이 없음 (하얀 도화지)

• 데이터 전달 보증 X

• 순서 보장 X

• 단순하고 빠름

• IP와 거의 같고, PORT , CHECKSUM정도만 추가

• 어플리케이션에서 추가 작업이 필요하다?

• TCP는 이미 규격이 정해져있어서 최적화 하기 어렵다.

• UDP는 최적화 가능

• TCP는 데이터 양도 많고 3 way hands 때문에 전송 속도가 느린 반면에 UDP는 아무것도 없기 때문에 상대적으로 전송 속도가 빠르다.

1. 비연결성: UDP는 데이터를 전송하기 전에 송수신자 간의 연결을 설정X 이는 데이터 전송을 시작하기 위한 초기 설정 시간이 필요 없음을 의미결과적으로 통신이 빠르게 이루어짐

2. 신속성

• 연결 설정이 없기 때문에, UDP는 데이터를 빠르게 전송할 수 있습니다. 이는 실시간 애플리케이션이나 대기 시간이 중요한 어플리케이션에서 유용하게 사용

3. 비신뢰성: UDP는 전송된 데이터의 도착을 보장X
   데이터 패킷이 손실되거나 순서가 바뀌어도, 재전송이나 순서 조정을 자동으로 수행 X 이는 네트워크 상태가 좋지 않거나 혼잡할 때 데이터 패킷의 손실 가능성이 있음을 의미합니다.

4. 효율성: 헤더 크기가 작고, 연결 관리에 드는 오버헤드가 없기 때문에, UDP는 네트워크 자원을 효율적으로 사용할 수 있습니다. 이로 인해 대역폭이 제한된 환경에서도 효과적으로 작동

5.다중 통신: UDP는 멀티캐스트와 브로드캐스트 전송을 지원 이는 한 번의 전송으로 여러 목적지에 데이터를 동시에 보낼 수 있음

• ex) 라디오 방송?

• 비연결성 : 누구나 조율해서 들음, 누가 듣는지 확인하지 않고 그저 송출

• 신속성 : 실시간으로 라디오방송은 정보를 전달, 일부 내용 누락되도 그냥 방송은 계속됨

• 효율성 : 라디오방송은 동시에 많은사람에게 전달될수있어서 좋음

• 다른 ex ) 실시간 비디오 스트리밍, 온라인 게임, 등..

TCP VS UDP

• TCP : 정확한 전송이 중요, 순서 무결성 보장. 웹페이지 로딩 및 파일전송 적합

• UDP: 실시간 데이터 전송 신속성 , 일부 패킷 손실가능

PORT

• ex ) IP 주소가 '어떤 집에 배달해야 할 편지'의 주소라면, 포트 번호는 '그 집 내에서 어느 방으로 편지를 가져다줘야 하는지

특징

• 특정 서비스 식별 : 각 네트워크 서비스는 특정 포트 번호 사용해서 식별 동시에 여러 네트워크 서비스

DNS

• 전화번호부: DNS는 인터넷의 전화번호부와 같습니다. 사람들이 친구의 이름을 알고 있듯이, 우리는 웹 사이트의 도메인 이름을 알고 있습니다. 전화번호부에서 친구의 이름을 찾아 전화번호를 알아내듯이, DNS 서버는 도메인 이름을 IP 주소로 변환

• 계층적 구조: 전화번호부가 지역별, 알파벳 순으로 정렬되어 있는 것처럼, DNS도 여러 계층으로 구성되어 있어 효율적으로 이름을 해석

• 동적 IP 주소 관리: 친구의 전화번호가 바뀌어도, 연락처에 업데이트만 되어 있다면 친구의 이름으로 쉽게 전화를 걸 수 있는 것처럼, 웹 사이트의 IP 주소가 변경되어도 도메인 이름은 변하지 않으며, DNS가 새로운 IP 주소로 이동 가능

URI (Uniform Resource Identifier)

• 자원을 식별하는 통합법?

• URI는 인터넷 상에서 자원(리소스)을 식별하는 표준화된 방식을 제공하는 문자열

• URI = URL + URN

• 리소스를 식별한다? (주민등록번호처럼..)

• URI는 로케이터(locator), 이름(name) 또는 둘 다 추가로 분류될 수 있다.

• URL: 리소스 위치 (A의 위치) / URN: 리소스 이름 (A)

• URN은 이런게있다 .. 스킵..

비유

• URI는 인터넷이라는 거대한 '디지털 도서관'에서 필요한 '자료'를 찾기 위한 '카탈로그 시스템'과 같은 역할

• 도서관 카탈로그(URI): 도서관의 카탈로그는 책, 잡지, DVD 등 도서관이 보유한 모든 자료를 찾기 위한 통합된 시스템입니다. 여기서 각 자료는 고유한 식별 번호(URI)를 가지고 있으며, 이 번호를 통해 원하는 자료를 정확히 찾아낼 수 있습니다.

• 자료의 다양성(Resource): 도서관에는 다양한 유형의 자료가 있습니다. 책에서부터 실시간으로 업데이트되는 데이터베이스까지, 모든 것이 카탈로그를 통해 식별 가능합니다. 이는 URI가 인터넷 상의 모든 종류의 자원을 식별할 수 있음을 의미합니다.

• 고유 식별 번호(Identifier): 도서관의 카탈로그에서 각 자료에 부여된 고유 번호는 그 자료만의 특징을 나타내며, 이를 통해 수많은 자료 중에서도 정확히 원하는 자료를 찾을 수 있습니다. 마찬가지로, URI는 인터넷 상의 자원을 구별하고 식별하는 고유한 정보를 제공합니다.

설명

• Uniform : 리소스 식별하는 통일된 방식

• Resource : 자원을 URI로 식별할수있는 모든것 (제한없음) / 실시간 교통정보 , 구분할수 있는 모든것

• Identifier: 다른항목과 구분하는 필요한 정보

• URL - Locator: 리소스 위치 지정 / URN - Name: 리소스에 이름 부여

URL (Uniform Resource Locator)

• Locator: 리소스가 실제로 존재하는 위치를 가리킵니다. 예를 들어, http://www.example.com/index.html은 웹 서버 상의 특정 페이지를 위치 지정

• 위치는 변할 수 있지만 이름은 변하지 않는다. URN이 이름으로 실제 리소스가 결과 나오는게 매핑 되어야 하는데 찾기가 어렵다.

• urn은 생략 그닥 중요하진않은거같다.

URL 분석

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

url 전체문법

Scheme

• URI(Uniform Resource Identifier)의 일부로, 리소스에 접근하기 위해 사용되는 프로토콜을 지정

• URI의 구조에서 가장 앞부분에 위치

• 도로(인터넷): 여러 종류의 차량이 다니는 도로망과 같습니다. 인터넷은 다양한 데이터와 정보가 이동하는 경로를 제공합니다.

• 차량 유형(스킴): 도로 위를 다니는 차량은 자동차, 오토바이, 자전거 등 다양한 유형이 있습니다. 마찬가지로, 인터넷 상에서 데이터는 HTTP, HTTPS, FTP 등 다양한 프로토콜(스킴)을 사용하여 전송됩니다.

• 자동차(HTTP): 가장 일반적으로 사용되는 차량으로, 웹 페이지 접속에 사용됩니다. 기본 포트인 80번을 사용하는 것은 일반 도로를 사용하는 것과 비슷합니다.

• 오토바이(HTTPS): 자동차와 비슷하지만, 보안 기능이 추가된 것으로 생각할 수 있습니다. 암호화를 통해 데이터를 보호하는 것은 안전 장비를 갖춘 오토바이를 타고 가는 것과 유사합니다. 기본 포트 443은 보안 도로를 사용하는 것에 비유할 수 있습니다.

• 자전거(FTP): 특정 목적(파일 전송)에 맞게 설계된 차량입니다. 특정 경로(포트)를 통해 파일을 전송하는 것은 자전거 전용 도로를 사용하는 것과 비슷합니다.

• 프로토콜 https 리소스에 접근하기 위해 사용되는 방법
• 호스트 명 : 리소스가 호스팅되는 서버의 주소 ( 밑에 부연설명 )
• 인터넷에 연결된 컴퓨터가 어디에 있는지, 그리고 어떻게 그 컴퓨터(서버)에 접근할 수 있는지를 알려주는 정보
• 포트번호
• path
• queryParaameter

비유

• 도서관(인터넷): 전 세계의 정보가 모여 있는 공간으로, 다양한 지식과 데이터가 저장되어 있습니다. 우리는 이 공간 안에서 필요한 정보를 찾아볼 수 있습니다.

URL 리소스

• 책(URL 리소스): 도서관 안에서 찾을 수 있는 특정한 정보나 내용을 담고 있습니다. 웹 상의 각각의 페이지, 이미지, 동영상 등이 이에 해당합니다.

도메인 이름

• 도서관의 색인 시스템(도메인 이름): 도서관의 색인 시스템은 책들이 어디에 분류되어 있는지 알려주는 역할을 합니다. 인터넷 상에서는 도메인 이름이 이와 같은 역할을 하여, 우리가 찾고자 하는 웹 사이트가 어느 '서버'라는 섹션에 있는지를 알려줍니다.

경로(path)

• 책의 정확한 위치(경로): 도서관에서 책의 정확한 위치는 책장과 칸을 통해 지정됩니다. 웹 상에서는 URL의 경로가 이 역할을 하여, 서버 내에서 원하는 정보(웹 페이지, 파일 등)가 정확히 어디에 있는지를 지정해 줍니다.

쿼리 스트링

• 책을 찾기 위한 특정 정보(쿼리 스트링): 때로는 도서관에서 특정 책의 특정 페이지를 찾고 싶을 수 있습니다. 인터넷에서는 쿼리 스트링이 이 역할을 하여, 웹 페이지 내에서 더 세부적인 정보를 요청할 수 있게 해줍니다.

• 주로 프로토콜 사용 ex )http , https, ftp 등..

---

웹 브라우저 요청 흐름

• 웹 브라우저가 어떻게 동작을 할까?

1. URL을 입력한다.

2. DNS 서버로 IP를 찾아내고 생략된 PORT는 scheme로 찾아낸다.

3. 웹 브라우저가 HTTP 요청 메시지가 생성된다.

4. SOCKET 라이브러리를 통해서 TCP/IP로 IP와 PORT 정보를 찾은 거를 3 way handshake 방식으로 서버랑 연결을 한다.

5. HTTP 요청 메시지는 OS에 있는 TCP/IP 계층으로 전달한다.

6. TCP/IP 계층에서 HTTP 요청 메시지에 패킷으로 감싼다.

7. 웹 브라우저가 만든 요청 패킷을 서버에서 도착하면 패킷을 열어서 HTTP 요청 메시지를 확인해서 서버가 해석한다.

8. 서버가 HTTP 응답 메시지를 만들어서 TCP/IP 패킷을 감싸서 클라이언트에게 도착하면 패킷을 열여서 HTTP 응답 메시지를 확인해서 클라이언트가 해석한다.

HTTP 응답 메시지

9. 웹 브라우저가 HTML 렌더링을 해서 클라이언트가 HTML 결과를 볼 수 있다.

HTTP 기본

HTTP 특징

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

클라이언트-서버 구조

• HTTP는 클라이언트(웹 브라우저)와 서버 간의 요청-응답 프로토콜을 사용합니다. 클라이언트가 서버에 페이지나 이미지 등의 리소스를 요청하면, 서버는 이에 대한 응답을 보냅니다.

• ex)
  손님(클라이언트)이 웨이터(서버)에게 음식(웹 리소스)을 주문하는 상황입니다. 웨이터는 주방에 주문을 전달하고, 요리된 음식을 손님에게 가져다 줍니다.

무상태 프로토콜(스테이스리스), 비연결성

• HTTP는 무상태 프로토콜로, 서버가 클라이언트의 이전 요청들을 기억하지 않습니다. 각 요청은 독립적이며, 서버는 요청 사이의 상태 정보를 유지하지 않습니다. 이는 서버의 처리를 단순화시키고 확장성을 높이지만, 연속된 요청 간에 정보를 공유하기 위해서는 별도의 방법(예: 쿠키)이 필요합니다.

• ex )

웨이터가 손님의 이전 주문을 기억하지 않는 것과 같습니다. 각 방문(요청)은 독립적이며, 손님이 레스토랑을 다시 방문할 때마다 새로 주문을 해야 합니다. 손님이 자주 오는 손님인지 웨이터는 기억하지 않습니다.

state ful / stateless

https://velog.io/@superkkj/HTTP-%EA%B8%B0%EB%B3%B8

• 데이터를 너무 많이 보냄..(단점) 무상태 특징 (헤더에 토큰 바디에 내용 같은?)

지속연결?

• HTTP(HyperText Transfer Protocol)는 웹에서 데이터를 주고받기 위한 프로토콜

• 하나의 TCP(Transmission Control Protocol) 연결을 통해 여러 HTTP 요청과 응답을 주고받을 수 있게 하는 것을 의미

• HTTP/1.1부터 기본적으로 채택된 기능

• Connection: keep-alive" 헤더를 통해 구현

• 연결을 유지함으로써 웹 페이지를 로딩하는 데 필요한 시간과 리소스를 줄일 수 있습니다

ex ) HTTP/1.0은 커피를 주문할 때마다 카페에 들어가 주문을 하고, 커피를 받은 후 카페를 나오는 것과 같습니다. 각 주문마다 카페에 들어가고 나오는 과정이 반복되므로 시간이 많이 걸립니다.

• , HTTP/1.1의 지속 연결은 카페에 한 번 들어가 여러 잔의 커피를 연달아 주문하고, 한 번에 여러 잔의 커피를 받아 나오는 것과 비슷합니다

• 카페에 들어가고 나오는 시간을 줄임으로써 전체적인 주문 과정이 훨씬 빨라집니다.

HTTP 메시지

• HTTP 통신은 간단한 구조의 메시지를 사용합니다. 요청과 응답 모두 시작 줄, 헤더(요청 또는 응답의 메타데이터를 포함), 선택적 본문(전송할 데이터)으로 구성됩니다.

• HTTP 메시지 구조에서 start-line, header, empty line(CRLF), message body로 4가지 구조로 나눈다.

• 시작 줄(Start-line): 이 줄은 요청이나 응답의 성격을 정의합니다. 요청 메시지에서는 사용자가 수행하려는 작업(예: GET, POST)과 대상 리소스의 URL, HTTP 버전이 포함됩니다. 응답 메시지에서는 HTTP 버전, 상태 코드(예: 200 OK, 404 Not Found), 그리고 상태 텍스트를 포함합니다.

• 헤더(Header): 메시지의 메타데이터를 포함하며, 이는 메시지의 본문을 해석하는 방법, 클라이언트와 서버 간의 세션 관리, 요청이나 응답의 특성을 설명하는 다양한 정보를 포함합니다.

• 빈 줄(Empty line): 헤더와 본문 사이에는 반드시 빈 줄이 있어야 합니다. 이 빈 줄은 CRLF (Carriage Return과 Line Feed, 즉 "\r\n")로 구성됩니다. 이는 헤더의 끝과 본문의 시작을 나타냅니다.

• 메시지 본문(Message body): 실제 전송하고자 하는 데이터를 포함합니다. 이 데이터는 HTML 문서, 이미지, JSON 객체 등 다양한 형태가 될 수 있습니다.

• EX)

HTTP 메시지 구조를 비유적으로 설명하자면, 일반적인 편지를 보내는 과정과 유사하다고 볼 수 있습니다.

• 시작 줄(Start-line)은 편지 봉투에 쓰는 수신자 주소와 비슷합니다. 여기서는 메시지가 어디로, 어떻게 전달되어야 하는지를 정의합니다.

• 헤더(Header)는 편지의 봉투에 붙이는 우표나 기타 안내 스티커와 같습니다. 이는 편지의 배송 방법, 송신자 정보, 수신 시 주의 사항 등을 알려주는 역할을 합니다.

• 빈 줄(Empty line)은 봉투를 열고 편지지의 내용이 시작되기 전의 공백과 같습니다. 이는 메시지의 헤더 부분이 끝났음을 나타내며, 이제 본문을 읽을 준비가 되었음을 의미합니다. (ENTER)

• 메시지 본문(Message body)은 편지지에 쓰여진 내용입니다. 이는 실제로 송신자가 수신자에게 전달하고자 하는 메시지를 담고 있습니다.

단순함 확장가능

• HTTP는 이해하고 구현하기 쉬운 프로토콜입니다. 또한, 새로운 메소드나 헤더를 추가하여 기능을 확장할 수 있어, 웹의 발전에 맞추어 성장할 수 있습니다.

---

HTTP METHOD

API URL 설계

• 리소스를 식별하는 가장 좋은 방법은 리소스에 대한 명확하고 직관적인 URI를 설계

• 리소스란 ? 웹에 접근하는 모든 것을 의미 회원정보... 상품목록 게시글등

• URI는 리소스를 고유하게 식별하며, 계층 구조를 사용하여 리소스 간의 관계를 나타낼 수 있습니다.

회원 리소스를 예로 들면:
회원 목록 조회: /members
특정 회원 조회: /members/{memberId}

• • 식별: URI는 리소스만을 식별하고 리소스에 대한
  • 행위(조회, 등록, 삭제, 변경)는 HTTP 메서드(GET, POST, PUT, DELETE)를 통해 구분

• GET / POST / PUT,PATCH / DELETE

음식을 주문하는 과정에 비유할 수 있습니다. 여기서 식당의 메뉴판이 '리소스' 목록이라고 할 수 있고, 손님이 주문서에 적는 행위(음식 주문하기, 추가 주문하기, 주문 변경하기, 주문 취소하기)가 HTTP 메서드에 해당합니다. 손님이 특정 음식(리소스)을 선택하고, 그에 대한 행위(주문서에 적음)를 통해 원하는 동작(조회, 등록, 변경, 삭제)을 요청하는 것과 같습니다.

PUT VS PATCH

• PUT은 리소스의 전체 교체를 의미합니다. 클라이언트가 리소스의 전체 상태를 정의하고, 이를 서버에 전달하여 전체를 교체하도록 요청합니다. 멱등성을 가지며, 동일한 요청을 여러 번 수행해도 같은 결과를 보장

• PATCH 리소스의 부분적인 변경을 위해 사용됩니다. 클라이언트는 변경하고자 하는 리소스의 일부만을 서버에 전달하고, 서버는 해당 부분만을 업데이트합니다. 멱등성은 구현에 따라 달라질 수 있습니다.

• PUT과 PATCH의 차이를 비유적으로 설명하자면, PUT은 집 전체를 새로 꾸미는 것에 비유할 수 있고, PATCH는 집의 일부만을 수리하거나 꾸미는 작업에 비유

• 흠... 어짜피 service로직에서 엔티티를 조회해 변경하는데

• 구분할 필요가있을까..

• https://www.qu3vipon.com/idempotence-of-patch

여기보고 다시 고민해보기

GET

• path에 자원을 주세요!!?

POST

• 신규 리소스 식별자 생성 /members/100
• 자원이 생성된 경로도 보내줌

• 그냥 정리하면 식별자에 따라 저장하는거아닌가?

• 새 리소스 생성: 새로운 메뉴를 주문하는 것과 같습니다. 메뉴가 주방에 전달되고, 주방에서는 그 주문에 따라 새로운 요리를 만들어냅니다.

• 요청 데이터 처리: 주문이 들어간 후, 주방에서는 여러 단계의 요리 과정을 거쳐 최종적으로 손님에게 요리를 제공합니다. 이 과정에서 주문(데이터)은 단순히 요리(리소스)를 만드는 것을 넘어, 주방의 작업 프로세스(서버에서의 처리 과정)를 통해 최종 결과물로 변환됩니다.

• 기존 자원에 데이터 추가: 기존에 주문한 메뉴에 추가 요청 사항을 전달하는 것과 같습니다. 예를 들어, 추가 토핑을 요청한다거나, 기존 주문에 사이드 메뉴를 추가하는 것 등입니다.

• 다른 메서드로 처리하기 애매한 경우: 메뉴판에 없는 특별한 요청이나, 복잡한 주문 사항을 전달할 때 주방장과 직접 대화를 통해 주문을 하는 것과 비슷합니다. 표준 방식으로 처리하기 어려운 요구사항을 전달하기 위해 사용됩니다.

• 어렵게 설명했는대.. 그냥 현업에선 저장의미 그이상은 아닌거같다.

PUT

• 폴더에 파일을 복사하는 거랑 비슷함.
  (완전히 대체한다는게 중요함)

• 리소스를 수정하는게아니라 완전히 대체해버린다.

메서드 속성

• ex) get은 단순 조회라 안전함
• 나머지는 불안전(변경이 일어나기 때문에)

멱등

캐시가능

• 웹 브라우저에 용량이 큰 이미지를 한번 요청을 하면 그 다음에 똑같이 용량이 큰 이미지를 요청할 필요없다. 똑같은 이미지를 서버에서 다운로드 받으면 오래 걸린다. 그래서 로컬 PC에 웹 브라우저 저장을 하고 있을 때 캐시

• 캐시 가능한 메소드(Cacheable Methods)란 웹 통신에서 사용되는 HTTP 메소드 중 하나이며, 이러한 메소드의 응답 결과를 캐시하여 재사용할 수 있음을 의미합니다. 캐시는 데이터를 임시 저장하는 공간을 말하며, 이를 통해 같은 요청을 할 때 마다 서버에 다시 접속하지 않고 빠르게 데이터를 불러올 수 있습니다. 캐시 가능한 HTTP 메소드에는 주로 GET과 HEAD가 있으며, 이 메소드들로 요청한 리소스의 응답은 변경되지 않는 한 캐시에 저장되어 재사용될 수 있습니다.

• 비유적인 설명으로는, 캐시를 도서관의 대출 책과 비교할 수 있습니다. 도서관에서 책을 대출하면, 그 책은 일정 기간 동안 대출자의 소유가 되어 반복해서 읽을 수 있습니다. 이 기간 동안 다른 사람이 같은 책을 찾으러 도서관에 가지 않아도 되듯이, 캐시 가능한 메소드로 얻은 데이터는 서버에 다시 요청하지 않고도 여러 번 사용할 수 있습니다. 즉, 처음 데이터를 요청할 때는 서버에서 정보를 가져와야 하지만, 그 이후로는 캐시된(도서관에서 대출한 책처럼 이미 가지고 있는) 데이터를 사용하여 시간과 자원을 절약할 수 있습니다

HTTP 메서드 활용

GET

• 보통 알고있는부분

• 쿼리파라미터는 주소뒤에 데이터를 넣어서 주로 필터?

• 정렬 조건도 들어가고, 한다.

post

• save 버튼을 formdata를 읽고 메시지 생성.
• 이런식으로 바디로 넘겨 데이터를 저장

• 이런식으로 정리..

• 요즘은 JSON 형식으로 보낸다.

• 결론은 GET은 조회용 POST는 회원가입이나 데이터 변경등에 사용

• 비유적인 설명

  • HTML Form을 통한 데이터 전송을 실생활의 예로 비유해 보겠습니다.

    POST 방식: 이는 마치 비밀 편지를 쓰고 봉투에 넣어서 보내는 것과 유사합니다. 편지의 내용(데이터)은 봉투 안에 안전하게 보관되어 외부에서 볼 수 없으며, 이를 받는 사람(서버)만이 봉투를 열어 편지의 내용을 볼 수 있습니다. 이 방식은 봉투가 훼손되지 않는 한 내용이 외부에 노출되지 않으므로 보다 안전합니다.

  • GET 방식: 이는 엽서에 메시지를 쓰고 보내는 것에 비유할 수 있습니다. 엽서의 내용은 누구나 볼 수 있으며, 주소(URI)와 메시지(데이터)가 모두 엽서의 한 면에 공개적으로 표시됩니다. 이 방식은 정보가 공개적으로 전송되기 때문에 민감한 정보를 보내기에는 적합하지 않습니다.

HTTP API 설계 예시

• 리소스 + 행위 -> 리소스(member) 만 식별해야됨.
• 클라이언트는 등록될 리소스의 URI를 모른다. 회원 데이터를 서버에 요청하고 서버가 알아서 회원을 식별해서 URI를 만들어준다.

POST

• 컬렉션(Collection)은 서버가 관리하는 리소스 디렉토리이다. 리소스의 URI를 생성하고 관리한다.

Collection?

• 컬렉션(Collection)은 웹 개발에서 자주 사용되는 개념으로, 서버 상에 저장된 리소스(자료)의 그룹 또는 디렉토리를 의미

• 이 컬렉션을 통해 클라이언트는 리소스의 생성, 조회, 수정, 삭제 등 다양한 작업을 할 수 있으며, 이러한 작업은 HTTP 메서드를 통해 이루어집니다. 특히, POST 메서드는 컬렉션 내에 새로운 리소스를 생성할 때 사용됩니다.

• 컬렉션(Collection)은 웹 개발에서 서버 상의 리소스를 그룹화한 것을 의미합니다. 각각의 컬렉션은 유사한 종류의 리소스들을 포함하며, 이러한 리소스들은 각기 고유한 URI(Uniform Resource Identifier)를 통해 식별됩니다. 컬렉션은 리소스의 집합으로, 웹 애플리케이션에서 데이터를 조직화하고 관리하는 데 중요한 역할을 합니다.

• 컬렉션의 특징과 작동 방식
  리소스 그룹화: 컬렉션은 비슷한 성격이나 목적을 가진 리소스들의 그룹입니다. 예를 들어, '사용자' 컬렉션은 여러 사용자의 프로필을, '게시물' 컬렉션은 여러 게시물을 포함할 수 있습니다.
  URI를 통한 관리: 각 리소스는 컬렉션 내에서 고유한 URI를 통해 접근 가능합니다. 컬렉션 자체도 고유한 URI를 가지며, 이 URI를 통해 컬렉션에 접근하고, 리소스를 추가, 조회, 수정, 삭제할 수 있습니다.
  HTTP 메서드와의 상호작용: 컬렉션과 리소스는 HTTP 메서드(GET, POST, PUT, DELETE 등)를 통해 조작됩니다. 예를 들어, GET 메서드를 사용해 특정 컬렉션의 리소스를 조회하거나, POST 메서드로 새 리소스를 해당 컬렉션에 추가할 수 있습니다.

• 비유적인 설명
  컬렉션을 이해하기 위한 비유적인 설명으로, 컬렉션을 대형 쇼핑몰의 다양한 상점들로 생각해볼 수 있습니다.

• 쇼핑몰 (웹 서버): 쇼핑몰은 여러 상점(리소스)들이 모여 있는 곳으로, 전체적으로 다양한 제품(데이터)을 제공합니다.
  상점 (컬렉션): 쇼핑몰 내의 각 상점은 특정 카테고리의 제품들을 판매합니다. 예를 들어, 한 상점은 의류를, 다른 상점은 전자제품을 취급할 수 있습니다. 이 상점들은 컬렉션에 해당하며, 각각의 제품(리소스)을 관리합니다.
  제품 (리소스): 각 상점에는 다양한 제품이 있으며, 이들 각각은 고유한 제품 코드(URI)를 통해 식별됩니다. 고객은 이 코드를 사용해 원하는 제품을 찾을 수 있습니다.
  쇼핑 (HTTP 메서드 사용): 고객이 상점에 들어가 제품을 보는 것은 GET 요청과 비슷하며, 새 제품을 구매(추가)하는 행위는 POST 요청에 해당합니다. 제품을 교환(수정)하는 것은 PUT 또는 PATCH 요청, 제품을 반품(삭제)하는 것은 DELETE 요청에 비유할 수 있습

상태코드

• 100은 거의 사용되지 않음

• 400 과 500의 차이
• 400은 클라이언트오류 똑같은 재시도가 있어도 계쏙 실패함
• 500대는 디비가 꺼졌다 다시 켜졌을때 성공 가능서이 있음?

• 입구에서 막는 예시?

• 보통 권한 관련된 문제.

• 500은 복구 가능성이 있다.

HTTP HEADER

• HTTP 전송에 필요한 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 등 모든 부가 정보를 헤더에 넣는다. 표준 헤더가 굉장히 많다.

분류

• RFC723x 변화 과거 RFC2616은 생략

• 엔티티를 표현으로 바뀌게됨 , 메타데이터 + 표현데이터
• 왜 표현이라 얘기할까?
  회원이라는 리소스를 HTML을 표현될 수도 있고
  회원이라는 리소스를 JSON으로 표현될수도 있고

Representation R은 Rest

• 메시지 본문을 페이로드라하고 요청이나 응답에서 전달할 실제데이터를 표현하는데 사용함.

표현

CONTENT-TYPE

• Content-Type은 HTTP 헤더의 일부로, 클라이언트(예: 웹 브라우저)와 서버 간에 전송되는 데이터의 종류를 나타냅니다.

• . 이 헤더는 데이터의 MIME 타입을 명시하여, 수신자가 어떻게 해당 데이터를 해석하고 처리해야 할지를 알려줍니다. MIME 타입은 타입/서브타입 형식으로 구성되며, 예를 들어 text/html, application/json, image/jpeg 등이 있습니다.

• 바디에 내용이 뭐야?

• 회원 리소스를 HTML 형식으로 전송할지 JSON 형식으로 전송할지 실제 리소스는 추상적이다. DB에 있을 수도 있고 Bytecode로 어딘가 저장되어 있을 수 있고 파일로 될 수 있다. 클라이언트랑 서버 간에 실제 주고 받을 때 이해할 수 있는 뭔가를 변환해서 데이터 전달해야 된다. 이때 헤더에다가 Content-Type을 사용한다.

Content-Type의 주요 용도

• 웹 브라우저에게 콘텐츠의 형식을 알림: 예를 들어, 서버에서 HTML 문서를 클라이언트로 보낼 때, Content-Type: text/html을 사용하여 이것이 HTML 문서임을 알립니다.
• 서버에 데이터를 전송할 때 데이터 형식을 명시: 예를 들어, 웹 양식을 통해 JSON 형식의 데이터를 서버로 전송할 때 Content-Type: application/json을 사용합니다.

• 비유적인 설명
  Content-Type을 설명하는 데 사용할 수 있는 비유는 음식에 대한 레시피입니다. 레시피는 음식을 만들기 위해 필요한 재료와 그 재료들을 어떻게 조합해야 하는지에 대한 지침을 제공합니다. 마찬가지로, Content-Type은 데이터가 어떤 형식인지를 설명하며, 이 정보를 바탕으로 데이터를 올바르게 해석하고 처리할 수 있도록 도와줍니다.

  • 예를 들어, Content-Type: application/json은 서버로부터 받은 데이터가 JSON 형식임을 나타내며, 이를 통해 웹 애플리케이션이 해당 데이터를 JavaScript 객체로 쉽게 변환하고 사용할 수 있음을 의미합니다. 이는 마치 레시피가 '이 음식은 오븐에서 굽는 것이 아니라, 프라이팬에서 볶아야 한다'고 명시하는 것과 유사합니다. 결국, Content-Type은 데이터를 올바르게 '조리'하는 방법을 알려주는 레시피와 같은 역할을 합니다.

Content-Encoding

• HTTP 헤더의 일종으로, 클라이언트와 서버 간에 전송되는 데이터가 어떤 방식으로 인코딩(압축)되었는지를 나타냅니다

• 이 헤더는 데이터 전송 효율을 높이기 위해 사용되며, 데이터를 압축하여 네트워크를 통한 전송 시간과 대역폭 사용을 줄일 수 있습니다

• gzip: GNU zip 압축을 사용합니다. 웹에서 가장 널리 사용되는 압축 방식 중 하나입니다.

• deflate: deflate 압축 알고리즘을 사용합니다. gzip보다 오래되었지만 여전히 흔히 사용됩니다.

• br: Brotli 압축을 사용합니다. 최신 압축 알고리즘으로, 효율적인 압축을 제공하여 웹 성능을 향상시킵니다.

• 비유적인 설명
  Content-Encoding을 우편 서비스에 비유해볼 수 있습니다. 우편물을 보낼 때, 크고 부피가 큰 물건을 가능한 한 작게 만들어 포장하여 우편 요금을 절약하고, 수령인이 물건을 더 빨리 받을 수 있도록 합니다. 예를 들어, 진공 포장을 사용해 공기를 빼내어 옷을 압축하면, 포장의 크기를 줄이고 배송 과정에서 필요한 공간을 최소화할 수 있습니다.

마찬가지로, Content-Encoding 헤더는 데이터를 압축하여 인터넷을 통해 전송할 때 필요한 공간(대역폭)과 시간을 줄여줍니다. 클라이언트가 데이터를 받았을 때는, Content-Encoding 헤더를 참조하여 어떤 압축 방식이 사용되었는지 확인하고, 해당 압축을 해제(예: 진공 포장된 옷을 개봉하여 원래의 크기로 확장)하여 원래의 데이터를 복원합니다.

이 비유를 통해, Content-Encoding은 데이터 전송의 효율성을 높이는 중요한 역할을 하며, 네트워크를 통한 데이터 전송 비용을 절감하고 전송 속도를 향상시키는 데 기여한다는 것을 이해할 수 있습니다.

쿠키

쿠키 미사용시

• http 는 무상태 프로토콜이기때문에
• 로그인한 사용자인지 알수 없다. 상태를 저장하지 않기 때문
• 모든 요청에 사용자 정보를 포함해서 보내면 해결되긴함.
• 이러면 보안문제가..?

쿠키 사용시

• 퀴 저장소에 저장! 자동으로 요청할때마다 쿠키값을 꺼내서 보냄

쿠키 상세설명

• 보통은 로그인 하면 세션키라는걸 쿠키에 만들어서 저장.
• 광고 정보 트래킹? 추적? -> 이 브라우저 사용자는 이런거 자주보는군!

쿠키 생명주기

쿠키 보안

Secure 속성

• 설명: Secure 속성이 있는 쿠키는 오직 HTTPS 프로토콜을 통해서만 전송됩니다. 이 속성은 쿠키가 암호화된 연결을 통해서만 서버로 전송되도록 하여, 중간자 공격을 통한 쿠키 절도를 방지합니다.
• 비유: Secure 쿠키는 마치 금고 안에 보관된 중요 문서와 같습니다. 문서가 금고 밖으로 나갈 때는 반드시 안전한 방법(여기서는 암호화된 통로)을 통해서만 이동하도록 합니다.

HttpOnly 속성

• 설명: HttpOnly 속성이 설정된 쿠키는 웹 서버를 통해서만 접근 가능하고, 클라이언트 측 스크립트(예: JavaScript)에서는 document.cookie를 통해 접근할 수 없습니다. 이는 크로스 사이트 스크립팅(XSS) 공격으로부터 쿠키를 보호하는 데 도움이 됩니다.
• 비유: HttpOnly 쿠키는 마치 특별한 권한을 가진 직원만이 접근할 수 있는 회사의 비밀 파일과 같습니다. 일반 직원(클라이언트 스크립트)은 그 파일을 볼 수 없으며, 오직 권한이 있는 직원(서버)만이 그것을 사용할 수 있습니다.

SameSite 속성

• 설명: SameSite 속성은 쿠키가 같은 사이트의 요청에 대해서만 전송되도록 제한합니다. 이는 크로스 사이트 요청 위조(CSRF) 공격을 방지하는 데 도움이 됩니다. SameSite 속성은 Lax, Strict, None 값으로 설정할 수 있으며, 각각의 값은 쿠키가 전송되는 방식에 대한 규칙을 달리 적용합니다.
• 비유: SameSite 쿠키는 마치 회사 내부에서만 사용되는 출입 카드와 같습니다. 카드는 회사 건물 내부에서만 유효하고, 외부 건물로 가지고 나갈 수 없습니다. 이를 통해 외부로부터의 무단 접근을 방지합니다.

XSS ?

• XSS(Cross-Site Scripting) 공격은 공격자가 사용자의 웹 브라우저에서 실행될 수 있는 악의적인 스크립트를 웹 애플리케이션에 삽입하는 보안 취약점을 이용한 공격

• XSS 공격의 유형

  • Stored XSS: 악의적인 스크립트가 웹 서버에 저장되며, 다른 사용자가 해당 페이지를 방문할 때마다 스크립트가 실행됩니다.
  • Reflected XSS: 악의적인 스크립트가 사용자의 요청에 포함되어 있으며, 서버는 이를 즉시 실행할 수 있는 응답으로 다시 보냅니다.
  • DOM-based XSS: 원래 서버로부터 받은 HTML 문서를 변경하지 않고, 클라이언트 측에서 DOM(Document Object Model)을 조작하여 스크립트가 실행되는 공격입니다.

• XSS 공격의 영향

  • 사용자 세션의 탈취, 즉 쿠키나 토큰 등의 인증 정보가 도난당할 수 있습니다.
  • 피싱 공격을 수행하여 사용자로부터 개인정보를 빼낼 수 있습니다.
  • 사용자의 웹 브라우저를 악용하여 다른 취약한 시스템에 공격을 가할 수 있습니다.

• XSS 공격을 "무단으로 낙서하기"에 비유할 수 있습니다. 예를 들어, 공공 장소의 게시판에 누군가가 스티커나 포스터를 허락 없이 붙여 놓는 것과 유사합니다. 이 스티커나 포스터에는 게시판을 보는 사람들이 스마트폰으로 특정 웹사이트를 방문하도록 유도하는 QR 코드가 있을 수 있습니다.

HTTP 헤더2 - 캐시와 조건부 요청

• 요청 -> 응답이미지와 관련된 총 1.1M

• 이런 문제점이 발생.
• 면접 질문에도 하나 나올듯?

캐시 적용

• 60초동안 응답결과를 브라우저 캐시에 저장

• 다음 요청땐 브라우저 캐시부터 찾는다.

• 캐시 적용으로 캐시 시간동안 네트워크 사용하지 않아도됨

• 비싼 네트워크 사용량 줄임

• 속도 상승

캐시 시간 초과?

• 다시 요청했을 시 데이터를 바꿔서 새로 갱신하거나

• 기존이랑 같으면 다시 다운로드?

• 클라이언트가 캐시된 데이터와 서버의 데이터가 동일한지를 확인하려고 할 때?

• 검증 헤더를 사용하여, 서버에 저장된 데이터의 최신 상태를 확인합니다. 서버는 데이터의 변동 여부에 대한 정보만을 클라이언트에게 전달합니다

검증 헤더

• Last-Modified 추가 -> 데이터의 최종 수정일

  • 60 초과? 검증헤더가 데이터 최종 수정일 요청헤더에 포함
    (캐시에 들고 있는..)

  • 서버에서 요청이 왔음 최종 수정일 날짜가 같다?

  • 날짜로 판단을 해보니 너꺼는 아직 써도되.! 신선함!!

  • 304 Not Modified 보내고. HTTP BODY 없이 보냄

  • 최종적으로 다시 씀 브라우저 캐시에 있는 파일을.

• 비유적인 설명

  • 도서가 갱신되었을 경우(데이터 변경):
    도서관에 가서 책을 대출하려고 할 때, 만약 책의 새로운 판이 나왔다면 당신은 새 판을 대출합니다.
    도서가 갱신되지 않았을 경우(데이터 불변):

  • 도서관에 가서 같은 책을 다시 대출하려고 할 때, 책의 판이 바뀌지 않았다면 이미 집에 있는 책을 계속 읽습니다.
    검증 헤더(ETag, Last-Modified):

  • 도서관에 전화를 걸어 새 판이 나왔는지만 물어보는 것과 비슷합니다. 새로운 판이 나오지 않았다면, 굳이 도서관에 가서 책을 가져올 필요가 없습니다. 이는 통신 비용을 절약해주는 효율적인 방법입니다.

  

검증 헤더와 조건부 요청 2