코딩baby의 성장기

[Java]정적 펙토리 메서드

정성윤TV — Tue, 8 Apr 2025 16:45:50 +0900

정적 팩토리 메서드란?

static 키워드를 붙여서 만든 객체 생성 전용 메서드이다. (static을 사용하면 객체 없이 바로 사용가능)
생성자 대신 객체를 만들고 초기값도 넣을 수 있다.

JPA에서 setter쓰지 않는게 좋다고 했는데 그것을 해결하기 위해 정적팩토리 메서드를 사용한다고 한다.

public class Member {
    private String name;

    // 생성자를 private으로 숨기고
    private Member(String name) {
        this.name = name;
    }

    // 정적 팩토리 메서드
    public static Member of(String name) {
        return new Member(name); // 내부에서 객체 생성 + 값 설정
    }

    public String getName() {
        return name;
    }
}

Member m = Member.of("홍길동");
System.out.println(m.getName()); //   홍길동 출력

이런 느낌~

여러개의 값을 넣고싶을 때

public class User {
    private String name;
    private int age;

    private User(String name, int age) {
        this.name = name;
        this.age = age;
    }

    public static User of(String name, int age) {
        return new User(name, age); // 내부에서 필드에 다 넣어줌
    }
}

User user = User.of("철수", 25);

장점

불변객체를 만들기 쉽다.

new 키워드 안 써도 됨

리턴 타입을 자유롭게 바꿀 수 있음

[네트워크] HTTP 헤더와 쿠키

정성윤TV — Sun, 30 Mar 2025 16:43:26 +0900

1. HTTP 헤더와 쿠키

HTTP 통신에서 헤더(Header)는 클라이언트와 서버가 주고받는 부가 정보를 담고 있으며,
쿠키(Cookie)는 클라이언트 측에 상태 정보를 저장하는 대표적인 방식이다.

1-1. HTTP 헤더란?

HTTP 메시지에서 요청 또는 응답에 포함되는 메타데이터이다.
브라우저 정보, 인증 정보, 콘텐츠 타입 등 다양한 정보를 전달한다.

ex) 예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐
시 관리 정보 등등

헤더 부분

1) 요청 헤더 (Request Header)

클라이언트가 서버에 요청할 때 함께 전송하는 정보

Host	요청 대상 서버의 도메인	Host: www.example.com
User-Agent	브라우저 및 운영체제 정보	User-Agent: Mozilla/5.0
Accept	클라이언트가 수용 가능한 데이터 형식	Accept: text/html
Cookie	클라이언트가 보유한 쿠키 전송	Cookie: sessionId=abc123
Content-Type	요청 데이터의 형식	application/json, application/x-www-form-urlencoded

2) 응답 헤더 (Response Header)

서버가 클라이언트에게 응답할 때 함께 전달하는 정보

Content-Type	응답 데이터의 MIME 타입	Content-Type: text/html
Content-Length	응답 바디의 길이 (byte)	Content-Length: 1024
Set-Cookie	클라이언트에 쿠키 설정 지시	Set-Cookie: sessionId=abc123; Path=/; HttpOnly
Cache-Control	캐싱 정책 설정	Cache-Control: no-cache
Location	리다이렉트 위치	Location: /login

1-2. 쿠키(Cookie)

쿠키는 클라이언트(브라우저)에 저장되는 소량의 데이터이다.
서버가 클라이언트에게 Set-Cookie 헤더로 쿠키를 설정하면,
이후 요청마다 클라이언트가 Cookie 헤더로 서버에 다시 전달한다.

1) 쿠키의 구조

• Set-Cookie: 서버에서 클라이언트로 쿠키 전달(응답)
• Cookie: 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달

• ex) set-cookie: sessionId=abcde1234; expires=Sat, 26-Dec-2020 00:00:00 GMT; path=/; domain=.google.com; Secur

name=value	쿠키 이름과 값	sessionId=xyz789
Path	전송될 URL 경로	Path=/mypage
Max-Age	쿠키 유효 시간(초)	Max-Age=3600 (1시간)
Expires	만료 날짜	Expires=Wed, 21 Oct 2025 07:28:00 GMT
Domain	적용할 도메인 범위	.example.com
Secure	HTTPS 연결에서만 전송	Secure
HttpOnly	자바스크립트 접근 금지	HttpOnly

2) 쿠키 동작 예시

쿠키 로그인

3) 쿠키 생명주기, 도메인, 경로, 보안

1-3. 쿠키의 주요 활용 목적

세션 관리	로그인 상태 유지, 인증 처리
개인화	사용자 설정(언어, 테마 등) 저장
트래킹	사용자 행동 분석, 광고 목적 (주의 필요)

1-4. 쿠키의 보안 관련 속성 요약

Secure	HTTPS 연결에서만 전송 (중간자 공격 방지)
HttpOnly	JS 접근 차단 (XSS 공격 방지)
SameSite	사이트 간 요청 시 쿠키 전송 제한 (Lax, Strict, None)

1-5. 쿠키의 한계

저장 용량 제한: 쿠키 1개당 약 4KB, 도메인당 총 20개 내외
클라이언트 저장: 사용자가 직접 삭제 가능
보안 이슈: 민감한 정보는 절대 저장 금지 (예: 비밀번호, 카드번호)

[네트워크] HTTP 상태코드

정성윤TV — Sun, 30 Mar 2025 16:14:17 +0900

1. HTTP 상태 코드

서버는 클라이언트의 요청을 처리한 후, 그 결과를 숫자 코드로 알려준다.
이 숫자가 바로 HTTP 상태 코드(Status Code)이다.

상태 코드는 세 자리 숫자로 구성되며, 첫 번째 숫자에 따라 응답의 성격이 분류된다.

1-1. 상태 코드 분류 요약

범위분류명의미

1xx	정보(Informational)	요청을 받았으며, 계속 처리 중
2xx	성공(Success)	요청이 정상적으로 처리됨
3xx	리다이렉션(Redirection)	추가 작업 필요 (다른 위치로 이동 등)
4xx	클라이언트 오류(Client Error)	클라이언트의 잘못된 요청
5xx	서버 오류(Server Error)	서버 측의 문제로 요청 처리 실패

1-2. 1xx (정보 응답)

지금은 사용을 거의 안 한다고 함.

100 Continue

계속 진행하라는 의미

클라이언트가 요청을 계속 보내도 됨

1-3. 2xx (성공 응답)

200 OK	성공	요청이 성공적으로 처리됨
201 Created	생성됨	POST 요청 등으로 리소스가 새로 생성됨
204 No Content	내용 없음	응답 바디 없이 성공 (삭제 등에서 사용)

1-4. 3xx (리다이렉션)

영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동
• 예) /members -> /users
• 예) /event -> /new-event

일시 리다이렉션 - 일시적인 변경
• 주문 완료 후 주문 내역 화면으로 이동
• PRG: Post/Redirect/Ge

웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동
(리다이렉트)

301 Moved Permanently	영구 이동	요청한 자원이 새 위치로 영구 이동됨
302 Found	임시 이동	자원이 임시로 다른 위치로 이동됨 (원래 위치 유지)
304 Not Modified	변경 없음	캐시된 자원 사용 가능, 서버 자원 변경 없음

영구 리다이렉션

- PRG: Post/Redirect/Get

POST로 주문후에 웹 브라우저를 새로고침하면?
• 새로고침은 다시 요청
• 중복 주문이 될 수 있다

• 그래서 PRG를 사용하면 중복주문X

일시 리다이렉션

그래서 뭐써야함?

자동 리다이렉션시에 GET으로 변해도 되면 그냥 302를 사용해도 큰 문제 없음.

1-5. 4xx (클라이언트 오류)

400 Bad Request	잘못된 요청	문법 오류 또는 파라미터 오류
401 Unauthorized	인증 필요	로그인이 필요함 (인증 안 됨)
403 Forbidden	금지됨	서버가 요청을 거부 (권한 없음)
404 Not Found	찾을 수 없음	요청한 리소스가 존재하지 않음

1-6. 5xx (서버 오류)

코드의미설명

500 Internal Server Error	내부 서버 오류	서버의 예기치 못한 오류
502 Bad Gateway	잘못된 게이트웨이	게이트웨이/프록시 서버가 잘못된 응답을 수신
503 Service Unavailable	서비스 이용 불가	서버가 과부하 또는 점검 중으로 응답 불가

1-7. 상태 코드 핵심 요약~~

2xx: 요청 성공 → 클라이언트 입장에서 "정상 처리됨"
4xx: 클라이언트 문제 → 요청 URL, 파라미터, 인증 등 오류
5xx: 서버 문제 → 서버 자체에서 오류 발생

[네트워크] HTTP 요청 방식 GET, POST, PUT, DELETE

정성윤TV — Sat, 29 Mar 2025 20:49:32 +0900

HTTP 요청 방식 (Method)

HTTP는 클라이언트가 서버에 무엇을 요청하는지를 표현하기 위해 다양한 요청 메서드를 제공한다.
가장 많이 사용되는 메서드는 GET, POST, PUT, DELETE 등이다.

2-1. 주요 HTTP 요청 방식 요약

GET	데이터 조회 (읽기)	게시글 목록 조회, 검색
POST	데이터 생성	회원가입, 로그인
PUT	데이터 전체 수정	게시글 전체 내용 변경
PATCH	데이터 일부 수정	게시글 제목만 수정
DELETE	데이터 삭제	게시글 삭제
OPTIONS	지원하는 메서드 확인	사전 요청 처리 (CORS 등)
HEAD	응답 헤더만 요청	리소스 존재 여부 확인용

2-2. GET 방식

데이터를 URL 뒤에 붙여서 전송 (쿼리스트링 방식)
주소창에 노출됨 → 보안에 취약
캐싱 가능 / 즐겨찾기 가능
주로 데이터 조회 용도

ex) GET /search?query=apple HTTP/1.1

2-3. POST 방식

데이터를 바디에 담아 전송
주소창에 보이지 않음 → 보안 상대적으로 우수
대용량 데이터 전송 가능
서버가 아직 실별하지 않은 새 리소스 생성
회원가입, 로그인, 결제 등 주로 사용

ex) POST /register HTTP/1.1 Content-Type: application/x-www-form-urlencoded username=kim&password=1234

2-4. PUT 방식

리소스 전체를 수정하거나 새로 생성할 때 사용 (파일을 덮어씌우기 처럼 수정 한다!!)
리소스가 있으면 대체
리소스가 없으면 생성
같은 데이터를 여러 번 전송해도 동일한 결과 (멱등성)
보통 특정 id에 해당하는 데이터를 전부 갱신
클라이언트가 리소스를 식별

ex) PUT /users/1 HTTP/1.1 Content-Type: application/json { "name": "Kim", "email": "kim@example.com" }

주의 하자!!

2-6. PATCH 방식

리소스의 일부만 수정할 때 사용
전체 데이터가 아닌 변경할 항목만 전송
PUT보다 효율적

ex) PATCH /users/1 HTTP/1.1 Content-Type: application/json { "email": "new@example.com" }

일부만 변경~

2-6. DELETE 방식

지정된 리소스를 삭제할 때 사용
요청 시 바디 없이 URI로 리소스를 식별

ex) DELETE /users/1 HTTP/1.1

2-7. OPTIONS 방식

특정 리소스가 지원하는 HTTP 메서드를 조회
브라우저가 CORS 사전 요청(Preflight) 시 사용
실제로 데이터를 처리하진 않음

2-8. HEAD 방식

응답 헤더만 받고, 바디는 받지 않음
리소스의 존재 여부 확인, 상태 확인용으로 사용
GET과 비슷하되, 본문을 제외

참고: 멱등성(Idempotent)이란?

같은 요청을 여러 번 보내더라도 결과가 동일한 것!!! 1000번을 쏴도 똑같아야 한다!!

[네트워크] HTTP 메시지 구조

정성윤TV — Sat, 29 Mar 2025 16:56:07 +0900

1. HTTP 메시지 구조

HTTP 통신은 클라이언트와 서버가 주고받는 메시지로 이루어지며,
이 메시지는 크게 요청(Request) 과 응답(Response) 두 가지로 나뉜다.

HTTP 메시지에 모든 것을 전송 할 수 있다!!

1-1. 요청 메시지 (Request Message)

클라이언트가 서버에 무언가를 요청할 때 보내는 메시지이다.

구성 구조

① 요청라인 (Request Line)

② 헤더 (Header)

③ 빈 줄 (CRLF)

④ 바디 (Body)

1) 시작라인 (start-Line)

메서드	클라이언트의 요청 방식	GET, POST, PUT, DELETE 등
요청 URI	요청 리소스의 경로	/index.html
HTTP 버전	사용 중인 HTTP 버전	HTTP/1.1

ex) GET /index.html HTTP/1.1

2) 헤더 (Header)

요청에 대한 부가적인 정보들이 포함된다.

예: 브라우저 종류, 언어 설정, 쿠키, 인증 토큰 등

Host	요청 대상 서버의 도메인	Host: www.example.com
User-Agent	클라이언트 정보 (브라우저 등)	User-Agent: Mozilla/5.0
Accept	클라이언트가 처리 가능한 MIME 타입	Accept: text/html
Cookie	클라이언트가 보유한 쿠키 정보	Cookie: sessionId=abc123

3) 바디 (Body) — 선택사항

GET 요청은 일반적으로 바디 없음
POST, PUT 요청은 이곳에 데이터가 담긴다

예시 (POST 요청의 바디): id=test&password=1234

1-2. 응답 메시지 (Response Message)

서버가 클라이언트의 요청에 대해 결과를 전달할 때 사용하는 메시지이다.

구성 구조

① 상태라인 (Status Line)

② 헤더 (Header)

③ 빈 줄 (CRLF)

④ 바디 (Body)

1) 상태라인 (Status Line)

HTTP 버전	응답 메시지의 HTTP 버전	HTTP/1.1
상태 코드	요청 처리 결과 숫자 코드	200, 404, 500 등
상태 메시지	상태 코드에 대한 설명	OK, Not Found 등

ex) HTTP/1.1 200 OK

2) 헤더 (Header)

응답에 대한 부가 정보가 담긴다.

예: 콘텐츠 타입, 길이, 서버 정보, 쿠키 설정 등

헤더 이름설명예시

Content-Type	응답 본문의 MIME 타입	text/html, application/json
Content-Length	응답 바디의 길이 (byte)	Content-Length: 1234
Set-Cookie	클라이언트에 쿠키 설정 지시	Set-Cookie: sessionId=xyz789

3) 바디 (Body)

실제 응답 데이터가 담기는 부분이다.
→ HTML, 이미지, JSON 등 다양한 형식이 사용된다.

ex) <html> <body>환영합니다!</body> </html>

1-3. 요청/응답 메시지 예시 정리

요청 메시지 예시

GET /hello HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (바디 없음)

응답 메시지 예시

HTTP/1.1 200 OK Content-Type: text/html Content-Length: 1024 <html>...</html>

이것이 핵심~

[네트워크] URL, URN, HTTP, 무상태

정성윤TV — Sat, 29 Mar 2025 16:17:18 +0900

0. URI (Uniform Resource Identifier)

자원을 식별하는 통합 규칙
→ 인터넷 상의 모든 자원을 고유하게 식별하기 위한 표현 방식
ex) https://www.example.com/images/logo.png

0. URL (Uniform Resource Locator)

자원이 "어디에 있는지(위치)"를 나타내는 주소
→ 우리가 브라우저 주소창에 입력하는 것이 바로 URL이다.
ex) https://www.example.com:443/users?id=10#section1

https: 프로토콜
www.example.com: 호스트
443: 포트 (생략 가능), 일반적으로 생략, 생략시 http는 80, https는 443
/users: 경로
?id=10: 쿼리 파라미터
#section1: 북마크(앵커)
일반적으로 생략, 생략시 http는 80, https는 443

URL만 잘 기억하자

1. HTTP(HyperText Transfer Protocol)

HTTP는 웹에서 클라이언트(브라우저)와 서버 간 요청-응답 통신을 위한 텍스트 기반의 프로토콜이다.
→ 사용자가 웹사이트에 접속할 때 브라우저가 HTTP 요청을 보내고, 서버가 이에 응답하는 구조.

→ HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전

주요 특징

비연결성(Connectionless): 요청 후 응답이 끝나면 연결이 끊김
무상태성(Stateless): 이전 요청 정보를 기억하지 않음
단순함
확장 가능: 쿠키, 세션, HTTPS 등 다양한 방식으로 기능 확장 가능

2. HTTP 요청과 응답

클라이언트 (브라우저) → 요청(Request) 서버 → 응답(Response)

요청 메시지 구조

요청라인: 요청 방식(GET, POST 등), 요청 URL, HTTP 버전 헤더: 브라우저 정보, 쿠키 등 본문(Body): 데이터 전송 (POST에서 주로 사용)

응답 메시지 구조

상태라인: HTTP 버전, 상태 코드 (200, 404 등) 헤더: 서버 정보, 응답 형식 본문(Body): 실제 콘텐츠 (HTML, JSON 등)

3. HTTP 주요 메서드

메서드설명

GET	서버에서 데이터 조회 (ex. 게시글 목록 가져오기)
POST	서버에 데이터 생성 요청 (ex. 회원가입)
PUT	전체 데이터 수정
PATCH	일부 데이터 수정
DELETE	데이터 삭제 요청

4. HTTP의 무상태성 (Stateless)

HTTP는 Stateless, 즉 서버가 클라이언트의 이전 요청 정보를 저장하지 않는다!

장점

서버 확장에 유리 (사용자 상태 저장 필요 없음 → 가볍고 빠름)
서버확장에 유리함

단점

로그인 상태 유지, 장바구니 등 사용자 상태 관리가 필요한 경우 별도 처리가 필요함
→ 이를 보완하는 기술: 쿠키, 세션, 토큰(JWT) 등

김영한-HTTPS 강의 정리

[네트워크] PORT, DNS

정성윤TV — Tue, 18 Mar 2025 22:59:44 +0900

1. PORT (포트)

포트란?

IP 주소가 네트워크 상의 장치를 식별한다면, 포트(Port)는 하나의 장치 내에서 실행 중인 특정 애플리케이션을 구분하는 역할을 한다.
하나의 컴퓨터(서버)에서 여러 개의 서비스(웹 서버, 메일 서버 등)가 실행될 수 있기 때문에 포트 번호를 통해 목적지를 명확하게 구분한다.

IP안에서 각자 식별할 수 있게 만들어 놓은거임!!!

포트의 특징

0 ~ 65535 범위의 숫자로 구성됨.
0 ~ 1023번 포트 (Well-Known Port)
→ 주요 네트워크 서비스에 할당된 포트 (운영체제가 예약함) 잘 알려저서 안씀.
1024 ~ 49151번 포트 (Registered Port)
→ 특정 애플리케이션을 위해 등록된 포트
49152 ~ 65535번 포트 (Dynamic/Private Port)
→ 일시적으로 사용되는 포트 (임시 연결)

주요 포트 번호

서비스포트 번호

HTTP (웹)	80
HTTPS (보안 웹)	443
FTP (파일 전송)	20, 21
SSH (원격 접속)	22
DNS (도메인 네임 시스템)	53
SMTP (메일 전송)	25
POP3 (메일 수신)	110

2. DNS (Domain Name System)

DNS란?

도메인 네임을 IP 주소로 변환하는 시스템
사람이 기억하기 쉬운 도메인 주소(예: google.com)를 숫자로 된 IP 주소(예: 142.250.74.14)로 변환해준다.
그냥 전화번호부 같은 거임!!

DNS가 필요한 이유

IP 주소는 기억하기 어렵다
→ 142.250.74.14 대신 google.com을 입력하여 접근 가능
IP 주소는 변경될 수 있다
→ 서버의 IP가 변경되더라도, 도메인을 통해 접속 가능
웹사이트 운영이 편리해진다
→ 여러 개의 서버(IP)로 로드 밸런싱 가능

DNS 작동 과정

사용자가 www.google.com 입력
로컬 DNS 서버에 www.google.com의 IP 주소를 요청
로컬 DNS 서버에 데이터가 없으면 **상위 DNS 서버(루트 네임서버)**에 요청
최종적으로 IP 주소를 찾아서 반환
사용자의 브라우저가 해당 IP 주소로 접속
DNS로 IP찼고 그IP로 접속함!!

DNS 서버의 역할

루트 네임서버: 최상위 DNS 서버, 도메인의 최상위 관리
TLD 네임서버: .com, .org, .net 등의 최상위 도메인을 관리
권한 네임서버: 개별 도메인의 IP 주소를 저장하고 관리

김영한-HTTPS 강의 정리

[네트워크] IP,TCP/IP, UDP

정성윤TV — Tue, 18 Mar 2025 22:39:30 +0900

0.인터넷 프로토콜 4계층

1. 인터넷 통신 개요

인터넷에서 컴퓨터 간 통신은 클라이언트-서버 모델을 기반으로 이루어진다. 한 컴퓨터가 요청을 보내면 다른 컴퓨터가 응답을 보내는 방식이다.

2. IP(Internet Protocol)

IP는 인터넷에서 데이터를 전달하는 핵심 프로토콜이다. 데이터를 패킷(Packet) 단위로 쪼개어 목적지 IP 주소로 전송한다.

- IP패킷 안에 있는 정보는 출발지 IP, 도착지 IP, 전송데이터, 기타 등등... 이 있다!!!

패킷 전달 예시

그러나 IP만으로는 안정적인 데이터 전송이 어렵다. IP의 한계:

비연결성: 대상이 없거나 서비스 불능 상태여도 패킷 전송 ex)상대 컴퓨터가 꺼저 있어도 전송을 한다...하지만 받지 못하겠지
비신뢰성: 패킷이 손실되거나 순서가 뒤바뀔 가능성이 있다.
프로그램 구분 불가능: 같은 IP에서 여러 개의 애플리케이션이 실행될 경우 구별 불가

이 문제를 해결하기 위해 전송 계층 프로토콜인 TCP와 UDP가 존재한다.

3. TCP (Transmission Control Protocol)

TCP/IP 패킷 정보

연결 지향적: 통신 전 3-way handshake를 통해 연결을 설정
데이터 전달 보장: 패킷 손실 시 재전송, 수신 확인(ACK) 메커니즘
순서 보장: 패킷이 순서대로 도착하도록 조정
신뢰성이 높지만 속도가 느리다!!!
→ HTTP, 이메일, 파일 전송 등 신뢰성이 중요한 서비스에 사용됨

3-way handshake

4. UDP (User Datagram Protocol)

UDP는 비연결형 전송 프로토콜로, 데이터를 빠르게 전송하는 것이 목표이다.

UDP의 특징

연결 설정 없음: 3-way handshake 없이 바로 데이터 전송
데이터 전달 보장 X: 패킷이 손실될 수 있음
순서 보장 X: 패킷이 순서대로 도착한다는 보장이 없음
단순한 구조: IP 프로토콜 + PORT + 체크섬 정도만 추가된 형태
빠른 속도: TCP보다 지연이 적고 실시간 성능이 중요할 때 적합!!

UDP는 신뢰성을 희생하는 대신 빠른 속도와 낮은 지연시간을 제공하는 프로토콜이다.

UDP의 활용 사례

실시간 스트리밍 (음성·영상 통화, IPTV, 게임)
→ 약간의 데이터 손실이 있더라도 빠른 전송이 중요
DNS (Domain Name System)
→ 빠른 요청-응답이 필요하며, 일부 데이터 손실이 발생해도 문제없음
사물인터넷 (IoT) 기기 통신
→ 가벼운 데이터 전송과 빠른 응답이 필요

5. TCP와 UDP 비교 요약

	TCP	UDP
연결 방식	연결 지향 (3-way handshake)	비연결형
데이터 전달 보장	O (손실 시 재전송)	X (손실 가능)
순서 보장	O	X
속도	느림 (오버헤드 큼)	빠름 (오버헤드 적음)
신뢰성	높음	낮음
용도	웹, 이메일, 파일 전송	스트리밍, 게임, VoIP

김영한-HTTPS 강의 정리

코딩baby의 성장기

[Java]정적 펙토리 메서드

정적 팩토리 메서드란?

여러개의 값을 넣고싶을 때

장점

[네트워크] HTTP 헤더와 쿠키

1. HTTP 헤더와 쿠키

1-1. HTTP 헤더란?

1) 요청 헤더 (Request Header)

2) 응답 헤더 (Response Header)

1-2. 쿠키(Cookie)

1) 쿠키의 구조

2) 쿠키 동작 예시

3) 쿠키 생명주기, 도메인, 경로, 보안

1-3. 쿠키의 주요 활용 목적

1-4. 쿠키의 보안 관련 속성 요약

1-5. 쿠키의 한계

[네트워크] HTTP 상태코드

1. HTTP 상태 코드

1-1. 상태 코드 분류 요약

1-2. 1xx (정보 응답)

1-3. 2xx (성공 응답)

1-4. 3xx (리다이렉션)

영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동 • 예) /members -> /users • 예) /event -> /new-event

일시 리다이렉션 - 일시적인 변경 • 주문 완료 후 주문 내역 화면으로 이동 • PRG: Post/Redirect/Ge

- PRG: Post/Redirect/Get

그래서 뭐써야함?

1-5. 4xx (클라이언트 오류)

1-6. 5xx (서버 오류)

1-7. 상태 코드 핵심 요약~~

[네트워크] HTTP 요청 방식 GET, POST, PUT, DELETE

HTTP 요청 방식 (Method)

2-1. 주요 HTTP 요청 방식 요약

2-2. GET 방식

ex) GET /search?query=apple HTTP/1.1

2-3. POST 방식

ex) POST /register HTTP/1.1 Content-Type: application/x-www-form-urlencoded username=kim&password=1234

2-4. PUT 방식

ex) PUT /users/1 HTTP/1.1 Content-Type: application/json { "name": "Kim", "email": "kim@example.com" }

2-6. PATCH 방식

ex) PATCH /users/1 HTTP/1.1 Content-Type: application/json { "email": "new@example.com" }

2-6. DELETE 방식

ex) DELETE /users/1 HTTP/1.1

2-7. OPTIONS 방식

2-8. HEAD 방식

참고: 멱등성(Idempotent)이란?

[네트워크] HTTP 메시지 구조

1. HTTP 메시지 구조

1-1. 요청 메시지 (Request Message)

구성 구조

1) 시작라인 (start-Line)

2) 헤더 (Header)

3) 바디 (Body) — 선택사항

1-2. 응답 메시지 (Response Message)

구성 구조

1) 상태라인 (Status Line)

2) 헤더 (Header)

3) 바디 (Body)

1-3. 요청/응답 메시지 예시 정리

요청 메시지 예시

응답 메시지 예시

[네트워크] URL, URN, HTTP, 무상태

0. URI (Uniform Resource Identifier)

0. URL (Uniform Resource Locator)

1. HTTP(HyperText Transfer Protocol)

주요 특징

2. HTTP 요청과 응답

요청 메시지 구조

응답 메시지 구조

3. HTTP 주요 메서드

4. HTTP의 무상태성 (Stateless)

장점

단점

[네트워크] PORT, DNS

1. PORT (포트)

포트란?

포트의 특징

주요 포트 번호

2. DNS (Domain Name System)

DNS란?

영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동
• 예) /members -> /users
• 예) /event -> /new-event

일시 리다이렉션 - 일시적인 변경
• 주문 완료 후 주문 내역 화면으로 이동
• PRG: Post/Redirect/Ge