본 캠프_20일차

졸용·2025년 3월 17일

TIL

목록 보기

21/144

(3월17일)

⭐ Spring 입문 - 1주차

Spring 입문 1주차_강의자료

⭐ 용어 정리

▸▸ 네트워크 - 인터넷(Internet)◂◂

인터넷(Internet)은 인터넷 프로토콜 스위트(TCP/IP)를 기반으로 하여 전 세계적으로 연결되어있는 컴퓨터 네트워크 통신망을 일컫는 말

해저 광케이블 → 물리적인 연결
인공위성 → 무선 통신

➡️ 유/무선 방식으로 이름에 걸맞은 World Wide Web(WWW)이 구축

▸▸ 인터넷 프로토콜 IP(Internet Protocol)◂◂

인터넷 프로토콜은 인터넷이 통하는 네트워크에서 어떤 정보를 수신하고 송신하는 통신에 대한 규약을 의미

→ 복잡한 인터넷 세상에서 데이터를 안전하게 전달하기 위해서 최소한의 규칙이 필요하기 때문

IP =❌= IP주소

IP 주소 : 최소한의 규칙(IP)을 지킬 수 있는 이유는 IP 주소 덕분 (쉽게 말하면 각 기기 간의 통신을 식별할 수 있는 전화번호)
- 인터넷 통신 시에는 지정한 IP 주소에 데이터를 Packet 이라는 단위로 전달
Packet : 소스 IP, 대상 IP를 포함하고 있어서 어떤 컴퓨터에 데이터를 전송할지 판별할 수 있다
- 소스 IP(출발지), 대상 IP(도착지)를 포함하고 있어서 어떤 컴퓨터에 데이터를 전송할지 판별할 수 있다
- 크게 헤더, 페이로드, 트레일러(수신여부 포함)로 구분
- ❗데이터를 주기만 하는 것이 아닌 받고 응답한다❗

▸ IP 방식의 문제점 ◂

1️⃣ 애플리케이션 구분 :

대상 컴퓨터의 어떤 프로그램에 사용될 데이터인지 구분할 수 없다

2️⃣ 비연결성 :

수신 대상의 현재 상태에 상관없이 데이터를 전송한다

3️⃣ 비신뢰성 :

패킷이 소실되는 경우가 발생
패킷의 손상여부를 송신, 수신측 모두 알 수 없다
패킷의 순서가 뒤죽박죽이 되어 섞여서 들어오는 경우가 발생 (용량이 큰 데이터의 경우 패킷이 여러개로 나뉘어져 전송)
패킷이 손실되거나, 오류가 발생하여도 데이터의 재전송을 진행하지 않는다

▸▸ TCP(Transmission Control Protocol) ◂◂

서버와 클라이언트 간에 데이터를 신뢰성 있게 전달하기 위해 만들어진 프로토콜

➡️ ❗IP 방식의 문제점들을 해결해주는 것이 TCP 프로토콜❗

3 Way HandShake

1️⃣ SYN 접속 요청

2️⃣ ACK 요청 수락 → ACK가 없다면 연결 실패

3️⃣ ACK → ACK 함께 데이터 전송 가능

SYN (Synchronize)란?
- 클라이언트가 서버에게 연결을 요청하는 첫 번째 단계
- 클라이언트는 서버에게 "연결을 시작하고 싶다"는 의사를 나타내기 위해 SYN 플래그가 설정된 패킷을 전송
- 패킷에는 시퀀스 번호도 포함되어 있고 데이터 전송 순서를 관리할 준비를 한다
ACK (Acknowledge)란?
- 서버가 클라이언트의 SYN 패킷을 받고, 이를 확인했다는 신호를 보내는 단계
- 서버는 클라이언트의 SYN 요청을 수락하며, 자신도 연결을 시작하고 싶다는 뜻을 담아 SYN 플래그와 함께 ACK 플래그가 설정된 패킷을 클라이언트에게 전송한다
- 이때, 서버는 클라이언트의 시퀀스 번호에 1을 더한 값을 ACK로 응답
데이터 전송 여부 : TCP를 통해 통신하면 데이터를 잘 받았다는 응답을 반환해준다
패킷 순서 : 패킷이 나뉘어져 올지라도 순서를 보장

➡️ ❗TCP는 신뢰성이 있지만 연결하는 과정, 데이터 전송에 시간이 많이 소요된다❗

항상 3 way handshake 과정을 거치는 만큼 속도가 느리기 때문

▸▸ UDP(User Datagram Protocol) ◂◂

비연결형, 비신뢰성 전송 프로토콜

✅ 장점

- 기능이 없고 연결을 하지 않는 대신 속도가 빠르다

- 데이터 무결성 검사 → 체크섬(Checksum)을 포함하고 있다 → 잘못된 데이터가 전송되지 않도록 만들어준다

- IP와 차이점으로 PORT 가 존재한다

❌ 단점

- IP 방식과 거의 비슷하다(비신뢰성)

TCP의 신뢰성 보장 기능은 많은 애플리케이션에 유용했지만, 실시간 통신이나 스트리밍 애플리케이션에서는 빠른 전송이 중요했기 때문에 UDP는 이러한 요구를 충족하기 위해 개발

▸ PORT ◂

같은 IP 내에서 프로세스 구분을 하기 위해서 사용

→ 쉽게 말해서 PORT는 아파트 호수와 같은 역할을 수행

TCP/IP Packet 구조

자주 사용되는 PORT

1️⃣ 0 ~ 65535 할당 가능

2️⃣ 이미 사용되고 있는 포트 (0 ~ 1023) → 사용하지 않는 것이 좋다
- FTP - 20, 21 (TCP)
- SSH - 22 (TCP)
- 텔넷 - 23 (TCP)
- SMTP - 25 (TCP)
- DNS - 53 (TCP/UDP)
- DHCP - 67 (UDP)
- HTTP - 80 (TCP)
- HTTPS - 443 (TCP)
- RDP - 3389 (TCP/UDP)
➡️ 실제 개발을 진행할 때 사용되지 않는 나머지 포트를 사용하여 개발

▸▸ DNS(Domain Name System) ◂◂

도메인 이름과 IP 주소를 서로 변환하는 역할을 수행

→ 사람이 읽을 수 있는 도메인 이름을 컴퓨터가 읽을 수 있는 IP 주소로 변환

DNS가 나오게된 이유

1️⃣ 컴퓨터 간의 통신을 위해선 IP 주소가 필요
- IP 주소는 사이트마다 특징도 없고 길어서 외우기가 힘들다
- IP 주소가 변경된다면 새로운 IP에 접근할 수 없다
2️⃣ IP는 변경되는 주소
- 일반적으로 가정집에서 사용되는 IP는 유동IP
- 만약 IP가 변경된다면 새로운 IP에 접근할 수 없다
DNS 동작 순서

1️⃣ 원하는 이름의 도메인을 구매 후, DNS 서버에 등록

2️⃣ 도메인 명을 입력하면 DNS 서버는 IP 주소를 반환

3️⃣ IP가 변경되면 DNS 서버에 등록된 IP 주소만 바뀌면 된다

4️⃣ 우리는 IP주소의 형태가 아닌 (https://spartacodingclub.kr/ 와 같은) 도메인 이름 형태로 웹에 접속

▸▸ URI(Uniform Resource Identifier) ◂◂

인터넷 자원(Resource)을 나타내는 고유 식별자(Identifier)를 뜻한다

Uniform : 자원(Resource)을 식별하는 통일된 방식을 의미

Resource : 자원(페이지, 텍스트, 이미지, 동영상, 파일 등)을 의미

Identifier : 식별자를 의미

URI(Uniform Resource Identifier)
- 인터넷 자원(Resource)을 식별할 수 있는 문자열을 의미
- URI는 Locator, Name 혹은 둘 다 추가로 분류될 수 있다
URL(Uniform Resource Locator)
- 자원(Resource)의 위치를 의미 (예 : 튜터가 있는 사무실)
- 일반적으로 도메인주소로 알려져있다
- 프로토콜 포함 (https: 와 같은)
URN(Uniform Resource Name)
- 자원(Resource)의 이름(Name)을 의미 (예 : 튜터)
- 리소스의 위치가 변경되어도 이름으로 리소스를 찾기 때문에 잘 동작
- 프로토콜을 포함하지 않는다
- URN으로 실제 리소스에 접근하는 방법은 대중화 되어있지 않다

▸▸ URL(Uniform Resource Locator) ◂◂

프로토콜을 포함한, 자원(Resource)의 위치를 나타낸다

URL 구조
- 구조 예시 scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment] → [ ] 안에 생략 가능
- 실제 예시 https://www.google.com:443/search?q=스파르타+코딩클럽
scheme
- 주로 프로토콜을 사용. 웹에서는 http, https, ftp를 주로 사용
user[:password]
- 사용자 정보
- URL은 보안에 취약하여 사용하지 않는다
host[:port]
- 호스트명 : 도메인 명(www.google.com) 또는 IP 주소를 직접 사용
- http : 80, https : 443 포트 사용
- 포트는 일반적으로 생략
[/path]
- 리소스의 경로
- ❗계층 구조로 구성❗
[?query]
- key=value 형태로 구성
- Query Parameter, Query String 이라고도 한다
- ❗?로 시작되고 &으로 구분❗
[#fragment]
- html 내부 북마크 등에 사용 → 전달받은 URL로 접속 시 특정 위치(fragment)로 이동할 수 있다
URL 방식의 한계

❗자원(Resource)의 위치를 변경하면 기존 URL은 사용할 수 없다❗ → 이러한 한계를 극복하기 위해서 URN이 등장

▸▸ URL 동작 정리 ◂◂

웹 브라우저에 URL을 입력하면 어떤 순서로 요청이 흘러가는지 예시를 통해 정리

1️⃣ https://www.google.com:443/search?q=스파르타+코딩클럽&hl=ko URL을 입력

2️⃣ DNS 서버를 조회하여 www.google.com 에 해당하는 IP 주소를 응답받기

3️⃣ 웹 브라우저에서 HTTP 요청 메세지를 생성

4️⃣ 요청 패킷(HTTP 메세지가 포함되어 있다)을 구글 서버로 전송

5️⃣ 구글 서버에서 HTTP 요청 메세지를 기반으로 응답 HTTP 메세지를 만들어 응답

6️⃣ 응답패킷 도착 → HTML 이 응답으로 온다 → 응답 결과가 브라우저에 그려진다

▸▸ 프로그래밍 명명 규칙 (Casing) ◂◂

1️⃣ snake case

Python 이나 DB Table, Cloumn 에 사용된다
문자와 문자 사이를 _ 언더바로 이어준다
모든 단어는 소문자이거나 대문자

2️⃣ camelCase

Java, JavaScript, TypeScript 에서는 변수, 함수, 메서드 이름을 만들 때 사용
문자와 문자 사이를 대문자로 이어준다

3️⃣ PascalCase

대부분의 프로그래밍 언어에서 클래스 이름 지정할 때 사용
문자의 처음 시작을 대문자로 한다
문자와 문자 사이를 대문자로 이어준다

4️⃣ kebab-case

문자와 문자 사이를 - 대시로 이어준다
모든 단어는 소문자

Java 의 명명법

▸▸ JSON ◂◂

JSON (Java Script Object Noatation)이란?

클라이언트와 서버가 통신할 때 사용하는 데이터 양식

클라이언트와 서버가 사용하는 언어에 관계 없이 통일된 데이터를 주고받을 수 있도록 만들어준다

사람, 기계 모두 이해하기 쉽고, 용량이 작다
XML 을 대체해서 데이터 전송 등에 많이 사용
Web 의 세계에서 JSON 을 공통어로 사용 (like 영어)

클라이언트 to 서버의 통신 → JSON 사용
서버 to 서버의 통신 → JSON 사용

▸▸ JSON 의 구조 ◂◂

{
  "user": [
    {
      "first_name": "wonuk",
      "last_name": "Hwang",
      "age": 100,
      "phone_agree": false,
      "hobby": ["Java", "Spring"]
    },
    {
      "firstName": "sparta",
      "lastName": "Team",
      "age": 200,
      "phone_agree": true,
      "hobby": ["React", "Spring", "Node"]
    },
  ]
}

snake_case, camelCase 모두 사용 가능
key-value 형태로 구성
null, number, String, array, object, boolean 형태의 데이터 사용 가능

▸▸ Scale Up, Scale Out ◂◂

서버의 성능 향상을 위한 두 가지 방법

1️⃣ Scale Up

수직적 확장
단일 서버의 하드웨어 사용을 높인다 ( CPU, Memory 등의 스펙을 높인다)
요청에 대한 처리를 더 빠르게 할 수 있도록 한다

2️⃣ Scale Out

수평적 확장
같은 사양의 서버(인스턴스)를 여러 대 배치
동시에 더 많은 사용자 요청을 처리할 수 있다

▸▸ Stateful, Stateless ◂◂

클라이언트와 서버간의 통신 상태 (state) 유지 여부에 따라 나뉘는 특성

1️⃣ Stateful

✅ 장점
- 클라이언트의 상태를 유지한다
- 클라이언트의 요청들을 기억(상태 유지)하여 다음 질문들에 대한 처리 가능
❌ 단점
- 같은 서버가 유지되어야 한다
- 상태를 유지하고 있던 서버가 종료되면 상태 유지 불가능 (서버는 다양한 이유로 동작하지 않을 수 있다)
- 요청 트래픽이 몰리게 되면 상태를 유지하는 것에 많은 Resource 가 소요된다

2️⃣ Stateless

✅ 장점
- 같은 서버를 유지할 필요가 없다
- Scale Out 수평 확장성이 높다 (갑자기 요청량이 증가해도 서버 증설하기 쉽다)
❌ 단점
- 클라이언트가 데이터를 추가적으로 전송해야 한다
- 전송되는 데이터릐 양이 많아진다

▸▸ Connection, connectionless ◂◂

클라이언트와 서버 간의 연결 (Connection) 유지 여부에 따라 나뉘는 특성

1️⃣ Connection

서버는 클라이언트와 연결 유지 위해 자원을 소모한다 → 아무런 요청 없어도 서버 유지

✅ 장점
- 새로운 연결 과정을 거치지 않아도 된다
- 그만큼 요청에 대한 응답 속도가 빨라진다
❌ 단점
- 클라이언트가 지속적으로 요청을 보낼거라는 보장이 없다
- 즉, 연결을 위한 자원이 낭비된다

2️⃣ Connectionless

서버는 클라이언트와 연결 유지하지 않는다 → 서버는 최소한의 자원만 사용

✅ 장점
- 서버 자원을 효율적으로 사용 가능
❌ 단점
- 추가 요청이 오면 연결 (3 way handshake) 을 새로 해야한다 → 요청에 대한 응답 시간 증가
- 웹 사이트의 HTML, CSS, JS, 이미지 등의 정적 자원 모두 다시 다운로드 한다 → 캐시, 브라우저 캐싱 (임시저장) 으로 해결
- 현재는 HTTP 지속 연결로 문제 해결
HTTP 지속 연결 (Persistent Connections)
- 하나의 요청에 필요한 요청들이 모두 응답될 때까지 연결 유지
- 연결을 한 번만 맺고 끊기 때문에, Connectionless 방식보다 연결 횟수가 적다 → 그만큼 빨라지는 속도

⭐ HTTP

▸▸ HTTP (HyperText Transfer Protocol) 특징 ◂◂

1️⃣ 클라이언트와 서버 구조

클라이언트는 UI 에 중접을 두도록 만들고, 서버는 데이터 & 비즈니스 로직을 담당하도록 만들었다 → 클라이언트, 서버 각자 독립적으로 발전 할 수 있게 됐다

2️⃣ 무상태 (Stateless) 의 특징을 가진다

3️⃣ 비연결 (Connectionless) 의 특징을 가진다

▸▸ HTTP Message 구조 ◂◂

HTTP Message 는 요청 메시지, 응답 메시지 두 종류가 있고, 각각 구조가 다르다

![](https://velog.velcdn.com/images/jess_kim/post/bc3c4444-f9ef-4f33-b144-963e84e9c6b5/image.png

▸ HTTP 요청 메세지(Request Message) ◂

1️⃣ Start Line

HTTP Method (CRUD 작업을 하게 된다)
- Create - Post 메서드와 연결된다
- Read - GET 메서드와 연결된다
- Update - PUT(전체), PATCH(일부) 메서드와 연결된다
- Delete - DELETE 메서드와 연결된다
- Request Target
path
- HTTP Request가 전송되는 대상, 절대 경로(”/”로 시작하는 경로. 예 : /event)
- Query String(= Query Parameter) 에 해당하는 값도 포함 (예 : /search?keyword=sparta)
HTTP Version

2️⃣ Header

상세 내용은 아래에 따로 기재

3️⃣ Empty Line

공백 한 줄
필수 값

4️⃣ Message Body

실제 전송하는 데이터가 담겨 있는 부분
byte로 표현되는 모든 데이터 전송 가능 (HTML, 이미지, JSON 등)
요청 시 GET 의 경우 Message Body가 지원되지 않는 경우가 많아 권장하지 않는다.

▸ HTTP 응답 메세지(Response Message) ◂

1️⃣ Start Line

HTTP Version
Status Code - 요청의 성공여부를 나타내는 코드
Status Text - 코드와 함께 전달될 메시지

2️⃣ Header

Response에서만 사용되는 Header 값들이 따로 존재한다.

3️⃣ Empty Line

4️⃣ Message Body

실제 전송하는 데이터가 담겨 있는 부분
만약 전송할 데이터가 없다면, Body가 공백으로 존재한다

▸▸ HTTP Method ◂◂

클라이언트와 서버 사이에 이루어지는 요청, 응답 데이터를 전송하는 방식

▸ 주요 메서드 ◂

POST
- 리소스 생성
- 주로 HTML FORM(회원가입, 게시글 작성 등)에 사용
- 요청 데이터를 처리하는 방식에 정해진것은 없다
- Message Body를 통해 요청 데이터를 전달
GET
- 리소스 조회
- Query String 미포함하는 경우 - GET의 경우 Message Body가 지원되지 않는 경우가 많아 권장하지 않는다
- Query String 포함하는 경우 - 서버에 추가적인 데이터 전송을 해야한다면, Message Body가 아닌 Query String(Query Parameter)를 사용한다
PUT
- 리소스 덮어쓰기
- POST와는 다르게 클라이언트 측에서 리소스를 식별하여 URI를 지정한다
- 기존 리소스가 존재하는 경우 - 리소스 전체 수정
- 기존 리소스가 존재하고 일부만 변경하는 경우 - 기존 리소스가 존재하면 완전히 덮어쓰기가 된다
- 기존 리소스가 없는 경우 - 리소스가 없으면 생성된다
PATCH
- 리소스 부분 수정
DELETE
- 리소스 삭제

▸ 기타 메서드 ◂

HEAD
- GET에서 Message Body를 제외하고 상태 줄과 헤더만 반환한다.
OPTIONS
- 대상 리소스에 대한 통신 가능한 Method를 설명한다.
CONNECT
- 대상 자원으로 식별되는 서버에 대한 터널을 설정한다.
- 잘 사용하지 않는다.
TRACE
- 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행한다.
- 잘 사용하지 않는다.

▸▸ HTTP Method 속성 ◂◂

HTTP Method 는 안전성(Safe), 멱등성(Idempotent), 캐시가능성(Cacheable) 속성을 가지고 있다

1️⃣ 안전성(Safe)

GET 메소드(조회)는 안전하다 → 저장된 데이터를 변환하지 않는다
POST, DELETE, PUT, PATCH 는 안전하지 않다 → 데이터를 생성, 수정, 삭제한다

1️⃣ 멱등성(Idempotent)

한번을 호출하거나 수천번을 호출하거나 항상 결과는 같다
- GET → 같은 결과가 계속 조회된다
- PUT → 수정해서 대체된 후의 결과는 계속 같다
- DELETE → 같은 요청을 여러번해도 삭제된 결과는 같다
- POST → 멱등성을 보장하지 않는다
요청이 실패한 경우 재시도 하기위해 필요하다
- 항상 결과가 같다면 마음껏 재시도 해도된다
- 만약 멱등하지 않다면, 중복 요청을 보내서는 안된다
- 복구 매커니즘에 사용한다
재요청 중간에 리소스가 변경되는것은 멱등성으로 고려하지 않는다.

1️⃣ 캐시가능성(Cacheable)

캐시(Cache)란? → 클라이언트가 서버에 한번 요청했던 데이터에 대해서 매번 요청할 때 마다 다시 전송할 필요가 없도록 웹 브라우저가 임시적으로 데이터를 보관하고 있는 장소
재사용을 위해 요청에 대한 응답을 저장할 수 있는가?
- GET, HEAD, POST 메소드는 캐시가 가능
- 일반적으로 GET, HEAD 정도만 캐시로 사용

▸▸ HTTP 상태 코드 ◂◂

HTTP 요청에 대한 처리 상태를 응답하는 코드로 Data 를 함께 응답한다. Spring 에서는 Response 를 커스텀하여 의미있는 메세지를 만들어 사용하기도 한다

➡️ 100 단위의 의미만 외우기

▸ 대표적인 HTTP Status Code ◂

1xx (정보)
- 요청 수신 후 처리중인 상태
- 잘 사용하지 않는다
2xx (성공)
- 정상 처리 완료된 상태
- 200 OK - 요청 성공
- 201 Created - 새로운 리소스 생성
- 202 Accepted - 요청이 수신되었으나 처리가 완료되지 않음 (주로 Batch 처리에서 사용)
- 204 No Content - 요청은 성공했지만, 응답 데이터가 없음
3xx (리다이렉션)
- 요청을 완료하려면 추가 행동이 필요한 상태
- 3xx 응답 + Location HTTP Header 가 있으면 Location 위치로 리다이렉트
4xx (클라이언트 에러)
- 클라이언트측 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없다
- 클라이언트의 요청이 잘못되었기 때문에, 같은 요청의 재시도는 실패
- 400 Bad Request - 클라이언트가 HTTP 요청 내용을 수정 후 보내야 한다
- 401 Unauthorized - 클라이언트가 리소스에 대한 인증(Authentication) 이 필요하다 → 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명
- 403 Forbidden - 서버가 요청을 받았지만 승인 거부 (주로 인가(Authorization) 관련문제)
- 404 Not Found - 요청한 리소스가 서버에 없다. 이를 이용하여 리소스를 숨겨놓기도 한다 (있지만 없는척 가능)
5xx (서버 에러)
- 서버 오류, 요청은 정상이지만 서버가 처리하지 못함
- 재시도하면 성공할 수 있다
- 실제 서버에서 문제가 발생한 경우 5xx Error이기 때문에 발생하지 않는것이 최선
- 500 Internal Server Error - 대부분 500으로 처리
- 503 Service Unavailable - 서비스 이용 불가 (Retry-After Header 를 사용하면 얼마 뒤에 복구되는지 응답할 수 있다)

▸▸ HTTP API 설계 ◂◂

HTTP API 설계 방법

1️⃣ HTTP API는 설계시 항상 리소스 식별을 기준으로 삼아야한다

2️⃣URI에 들어갈 리소스는 단수 형태가 아닌 복수 형태로 사용을 권장한다 (board → boards)

3️⃣ URL에 동사를 사용하지 않는다

4️⃣ HTTP Method의 역할을 URL에 포함하지 않는다

▸▸ HTTP Header ◂◂

클라이언트와 서버가 요청 또는 응답으로 부가적인 정보 (Message Body 내용, 크기, 인증, 브라우저 정보, 서버 정보 등) 를 전송할 수 있도록 만들어 준다

Header 구조
- Host (예 : spartacodingclub.kr)
- field-name: OWS field-value OWS (OWS 는 띄어쓰기 허용한다는 뜻) 구조를 가진다
- field-name 은 대소문자 구분을 하지 않는다.
- 임의의 Header를 추가할 수 있다. (단, 서버가 값을 알고 있어야 함)
- 요청의 추가 정보들을 가지고 있다 (예 : Message Body 내용, 크기, 인증, 브라우저 정보, 서버 정보 등
- 각각의 헤더는 하나의 줄로 구분된다
- 텍스트 (plain text) 로 이루어져 있다
실제 HTTP Header 확인하는 방법
- 실제 브라우저는 하나의 화면을 구성하기 위해 수많은 HTTP 통신을 진행한다
- 개발자도구(F12) → Network 탭 클릭 → Fetch/XHR 탭 클릭 → 우측 Header 정보

졸용

꾸준한 공부만이 답이다

이전 포스트

본 캠프_19일차

다음 포스트

본 캠프_21일차

1개의 댓글

양재호

2025년 3월 17일

많은 내용을 깔끔하게 정리하셨네요 잘 보고 갑니다!

답글 달기