▶ Java 코드카타 문제 풀이
▷ 53. 명예의 전당(1)
● 문제 풀이 시 요구사항
- 명예의 전당은 총 k개만 들어갈 수 있다.
- 매일 발표된 명예의 전당의 최하위 점수를 저장한다.
● 코드
● 코드 설명
1. 먼저 최하위 점수들을 저장할 answer 배열과 명예의 전당인 list를 선언한다.
2. score 배열의 크기만큼 반복하는 반복문을 제작한다.(배열의 크기=일 수)
3. 명예의 전당에 배열 순서대로 점수를 등록하고 점수가 낮은 순으로 정렬한다.
4. 만약 명예의 전당 리스트의 크기가 k보다 클 경우 맨 앞의 점수를 삭제한다.(정렬을 했기 때문에 가장 낮은 점수가 없어진다.)
5. 명예의 전당 리스트의 가장 앞에 있는 점수를 배열에 저장하는 것을 반복한다.
◎ Spring 입문 1주차
▶ 네트워크
▷ TCP(Transmission Control Protocol)
서버와 클라이언트 간에 데이터를 신뢰성 있게 전달하기 위해 만들어진 프로토콜
● 3 Way HandShake
3번의 논리적 연결을 의미한다.(말 그대로 3번 악수하는 것)
패킷에 SYN, ACK를 붙여서 패킷의 용도를 나타낸다.
○ SYN(Synchronize)
- 클라이언트가 서버에게 연결을 요청하는 첫 번째 단계
- 서버에게 "연결을 시작하고 싶다"는 의사를 나타내기 위해 SYN 플래그가 설정된 패킷을 전송한다.
- 해당 패킷에는 시퀸스 번호도 포함되어 있고 데이터 전송 순서를 관리할 준비를 한다.
○ ACK(Acknowledge)
- 서버가 클라이언트의 SYN 패킷을 받고, 이를 확인했다는 신호를 보내는 단계
- 서버는 요청을 수락하며 자신도 연결을 시작하고 싶다는 뜻을 담아서 SYN 플래그와 함깨 ACK 플래그가 설정된 패킷을 클라이언트에게 전송한다.
- 이때, 서버는 클라이언트의 시퀸스 번호에 1을 더한 값을 ACK로 응답한다.
※ 요청 과정
1. 클라이언트가 서버에게 SYN 패킷을 보내서 접속을 요청
2. 서버가 이를 받고 요청 확인 및 접속 요청을 위해 SYN, ACK 패킷을 보냄
→ ACK가 없으면 연결이 실패했다는 걸 의미한다.
3. 클라이언트가 서버에서 보낸 SYN, ACK 패킷을 받고 요청을 확인했다는 ACK 패킷을 보낸다.
● 데이터 전송 여부
TCP를 통해 통신하면 데이터를 잘 받았다는 응답을 반환한다.
(SYN 패킷을 보내면 ACK 패킷을 받는 것)
● 패킷 순서
패킷이 나뉘어져 올지라도 순서를 보장한다.
▷ UDP(User Datagram Protocol)
비연결형, 신뢰성이 없는 전송 프로토콜이다. 실시간 통신이나 스트리밍 애플리케이션에서는 빠른 전송이 중요했기 때문에 현대에서는 UDP를 많이 사용하게 된다.
● UDP의 특징
○ IP 방식과 거의 비슷하다
- 3 way handshake를 하지 않아 데이터 전송, 응답, 순서를 보장하지 않는다.(비신뢰성)
○ 추가적인 기능이 거의 없다.
- 기능이 없고 연결을 하지 않는 대신 속도가 빠르다.
○ PORT가 존재한다.
＊ TCP에도 PORT가 존재한다.
○ 데이터 무결성 검사
→ 체크섬(checksum)을 포함하고 있다.
- 잘못된 데이터가 전송되지 않도록 만들어준다.
▷ PORT
같은 IP에서 동시에 여러가지 프로그램을 실행시키고 있을 때, 패킷의 도착지를 식별하기 위해 사용하는 기술이다.
ex) 택배기사가 아파트에 택배를 전달할 때 아파트의 호수를 보고 구분한다.(호수=PORT)
● TCP/IP 패킷 구조
○ 패킷 안에 소스 IP와 대상IP가 있으며 그 안에는 소스 PORT와 대상PORT가 있다.
● 자주 사용하는 PORT포트 번호는 0 ~ 65535까지 사용할 수 있지만 이미 사용되고 있는 포트가 존재한다.
○ 이미 사용되고 있는 포트국제 도매인 관리 기구에 의해 관리되고 있으며, 사용하지 않는 것이 좋다.
- 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)
※ 위의 포트를 제외한 나머지 포트를 사용하여 개발을 하면 된다.
▶ Web 기초
▷ DNS(Domain Name System)
도메인 이름과 IP 주소를 서로 변환하는 역활을 수행한다.(사람이 읽을 수 있는 도메인 이름을 컴퓨터가 읽을 수 있는 IP 주소로 변환하기 위해서)
● DNS가 나오게된 이유
○ 컴퓨터 간의 통신을 위해선 IP 주소가 필요하다.
- IP주소는 사이트마다 특징도 없고 길어서 외우기가 어렵다
- IP주소가 변경된다면 새로운 IP에 접근할 수 없다
○ IP는 변경되는 주소이다.
- 일반적으로 사용되는 IP는 유동IP이다.
- IP가 변경된다면 새로운 IP에 접근할 수 없다.
● DNS 동작 순서
1. 원하는 이름의 도메인을 구매 후, DNS 서버에 등록한다.
→ DNS 서버에는 도메인 이름과 IP주소가 저장된다.(도메인 이름 ↔ IP 주소)
2. 도메인 명을 입력하면 DNS 서버는 IP 주소를 반환한다.
ex) 크롬에 도메인 주소를 입력하면 해당 사이트로 이동하게 되는 것
＊ 진행 방식클라이언트가 DNS 서버에 도메인 이름으로 요청
→ DNS 서버는 해당 도메인 이름으로 저장된 IP 주소를 응답(Map에서 key 값을 받으면 value를 return 하는 것과 같다)
→ 클라이언트는 해당 IP로 접속한다.
3. IP가 변경되면 DNS 서버에 등록된 IP 주소만 바뀌면 된다.
▷ URI(Uniform Resource Identifier)
인터넷 자원을 나타내는 고유 식별자를 뜻한다.
● Uniform : 자원을 식별하는 통일된 방식을 의미한다.
● Resource : 자원(페이지, 텍스트, 이미지, 동영상, 파일 등)을 의미한다.
● Identifier : 식별자를 의미한다.
● URI
○ 인터넷 자원을 식별할 수 있는 문자열을 뜻한다.
○ URI는 Locator, Name 혹은 둘 다 추가로 분류될 수 있다.
● URL(Uniform Resource Locator)
○ 자원의 위치를 의미한다.
○ 일반적으로 도메인 주소로 알려져있다.
○ 프로토콜을 포함한다.(https://spartacodingclub.kr/)
● URL 방식의 한계
○ 자원의 위치를 변경하면 기존 URL은 사용할 수 없다.
● URN(Uniform Resource Name)
○ 자원의 이름을 의미한다.
○ 리소스의 위치가 변경되어도 이름으로 리소스를 찾기 때문에 잘 작동한다.
○ 프로토콜을 포함하지 않는다.
▷ URL
● 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]
○ 리소스의 경로
○ 계층 구조로 구성되어있다.
ex) https://nbcamp.spartacodingclub.kr/backend→ nbcamp. spartacodingclub.kr의 backend
● [?query]
○ key=value 형태로 구성
○ Query Parameter, Query String 이라고도 한다.
○ ?로 시작되고 &으로 구분된다.
ex) ?key1=value1&key2=value2&key3=value3
● [#fragment]
○ html 내부 북마크 등에 사용된다.
- 전달받은 URL로 접속 시 특정 위치(fragment)로 이동할 수 있다.
▶ HTTP
▷ HTTP(HyperText Transfer Protocol)
● HTTP 동작 순서○ 클라이언트는 Request(요청)을 보내고, 응답을 기다린다.○ 서버는 요청에 대한 처리를 수행 후 결과를 Response(응답)한다.
▷ HTTP 특징1. 클라이언트와 서버 구조● 기존에는 클라이언트, 서버가 구분되어있지 않았다.○ 클라이언트는 UI에 중점○ 서버에서 데이터, 비지니스 로직을 담당하도록 만들었다.
● 결과적으로 클라이언트, 서버 각자 독립적으로 발전할 수 있게 되었다.
2. 무상태(Stateless)● 서버는 클라이언트의 상태를 보존하지 않는다.
● 장점○ Scale Out 수평 확장성이 높다.○ 갑자기 요청량이 증가하여도 서버를 증설하기 쉽다.
● 단점○ 클라이언트가 데이터를 추가적으로 전송해야 한다.
● 한계점○ 무상태로 설계할 수 없는 경우가 있다.○ 로그인은 어떻게 해야할까?→ Cookie, Session, Token 등을 활용한다.
3. 비연결(Connectionless)● HTTP는 연결을 유지하지 않는 모델이다.
● 장점○ 서버 자원을 효율적으로 사용할 수 있다.
● 단점○ 요청이 추가적으로 오게되면 연결(3 way handshake)을 새로 해야한다.→ 즉, 요청에 대한 응답 시간이 증가하게 된다.○ 웹 사이트의 HTML, CSS, JS, 이미지 등의 정적 자원 모두를 다시 다운로드 한다.→ 캐시, 브라우저 캐싱 같은 임시저장을 활용하여 해결한다.○ 현재는 HTTP 지속연결(Persistent Connections)로 문제를 해결한다.
※ HTTP 지속연결
● 하나의 요청에 필요한 요청들이 모두 응답될 때 까지 연결을 유지한다.
● 연결을 한번만 맺고 끊기 때문에, 비연결 방식보다 연결 횟수가 적다
→ 그 만큼 속도가 빨라졌다.
'TIL' 카테고리의 다른 글
| CH3 일정 관리 과제 TIL (0) | 2025.02.03 |
|---|---|
| 내일배움캠프 TIL 21. (1) | 2025.01.23 |
| 내일배움캠프 TIL 19. (0) | 2025.01.21 |
| 내일배움캠프 TIL 18. (0) | 2025.01.20 |
| CH2 키오스크 과제 TIL (0) | 2025.01.19 |