Keep Coding

SYN 패킷 처리 딥다이브(번역 + 추가)

Joonon — Sun, 7 Nov 2021 18:23:57 +0900

3 way handshake은 정확한 전송을 보장하기 위해 단말 간에 세션을 수립하는 과정입니다. SYN synchronization packet과 ACK acknowledgment packet을 사용합니다. 클라이언트에서 SYN(a)을 보내고, 서버는 SYN(b), ACK(a+1)을 보내고, 클라이언트는 다시 ACK(b+1)을 보냅니다.

그런데 궁금한 것이 생겼습니다. 그럼 내부적으로는 SYN 패킷 관련 처리를 어떻게 하는 것일까요? SYN 패킷은 무한정으로 받을 수 있을까요?

이 글은

궁금증을 해결하기 위해 검색하다가 찾은 SYN에 대한 정말 좋은 글(영문)을 보고, 부가적인 설명을 곁들이며 정리한 글입니다.

실제 서버 운영 경험이 많은 Cloudflare에서 이와 관련해 깊게 파헤치는(원문: black art) 것을 게을리하지 않아 준 것이 감사하네요. 이 글의 번역에서도 큰 도움을 받았습니다.

클라우드플레어는 미국 소재의 CDN 서비스와 DNS 서비스를 제공하는 기업으로, 본사는 미국 샌프란시스코에 있습니다.
2021년 기준 전 세계 웹사이트 5개 중 1개가 클라우드플레어의 Reverse Proxy 서비스와 DNS server를 사용할 정도인 인터넷업계의 거인입니다.

이 글을 이해하기 위한 TCP 3 way handshake에 관해서는 제 전 포스팅을 읽어 주세요.

들어가며

사람들이 그다지 신경쓰지 않는 주제 중 SYN floods가 있습니다. Cloudflare는 리눅스를 사용하고 있는데 리눅스에서 SYN 처리는 정말로 복잡합니다. 이 글에서 이 주제를 깊게 파헤쳐 보겠습니다.

두 개의 큐에 대한 이야기

https://blog.cloudflare.com/syn-packet-handling-in-the-wild/

listen이나 연결을 위한 준비 상태의 소켓 (bound socket)은 LISTENING TCP 상태에 두 개의 분리된 큐를 가집니다.

SYN Queue
Accept Queue

일반적으로 이 큐에는 reqsk_queue, ack backlog, listen backlog, TCP backlog 등 다양한 이름이 있지만 혼선을 피하기 위해 위의 이름으로 정하고 시작하겠습니다.

SYN Queue

SYN 큐는 수신한 SYN 패킷(구체적으로는 struct inet_request_sock)을 저장합니다. 이는 SYN+ACK을 보내고 타임아웃시에 재시도하는 역할을 합니다. 리눅스에서 재시도 값은 다음과 같이 설정됩니다:

$ sysctl net.ipv4.tcp_synack_retries
net.ipv4.tcp_synack_retries = 5

Docs는 다음과 같습니다:

tcp_synack_retries - 정수

수동 TCP 연결 시도에 대해서 SYN+ACK를 몇번 다시 보낼지를 지정한다.
이 값은 255 이하이어야 한다. 기본값은 5이며, 1초의 초기 RTO값을 감안하면
마지막 재전송은 31초 후에 일어난다. 이는 수동 TCP 연결의 최종 타임아웃은
63초 이후에 일어난다는 것을 의미한다.

이를 표로 나타내면:

Time	Description
+0초	SYN+ACK 전송 (timeout=RTO=1초)
+1초	새 timeout = 1 x 2 = 2초. SYN+ACK 재전송	retry=1
+3초	새 timeout = 2 x 2 = 4초. SYN+ACK 재전송	retry=2
+7초	새 timeout = 4 x 2 = 8초. SYN+ACK 재전송	retry=3
+15초	새 timeout = 8 x 2 = 16초. SYN+ACK 재전송	retry=4
+31초	새 timeout = 16 x 2 = 32초. SYN+ACK 재전송	retry=5
+63초	tcp_synack_retries(5). 종료	timeout

계산하면 최초 SYN+ACK를 전송하고 31초 후에 마지막 재전송이 이루어지고, 32초까지 응답이 없으면 RTO 값 1초를 더한 63초 후에 세션이 종료됩니다.

즉, net.ipv4.tcp_synack_retries 값이 디폴트인 5로 설정되어 있다면 한 세션당 타임아웃 값은 63초가 됩니다.

SYN+ACK를 전송한 뒤에 SYN 큐는 3방향 악수의 마지막 단계인 클라이언트로부터의 ACK 패킷을 기다립니다. 수신된 ACK 패킷은 모두 완전히 수립된 연결 테이블에서 찾을 수 있어야 하며 관련된 SYN 큐에는 없어야 합니다.

SYN 큐에서 찾을 수 있다면, 커널은 해당 연결을 SYN 큐에서 제거하고 완전히 수립된 연결을 만들어 (struct inet_sock) Accept Queue에 추가합니다.

Accept Queue

Accept 큐는 애플리케이션이 언제라도 가져갈 수 있도록 완전히 수립된 연결을 저장하고 있습니다. 프로세스가 accept()를 호출하면 이 큐에서 소켓을 제거하며 애플리케이션에게 전달합니다.

이는 리눅스에서의 SYN 패킷 처리를 매우 간략하게 표현한 것인데, TCP_DEFER_ACCEPT나 TCP_FASTOPEN의 경우에는 약간 다르게 동작합니다.

큐 크기 제한

Accept와 SYN 큐의 최대 크기는 애플리케이션이 호출하는 listen 시스템 콜의 backlog 파라미터로 전달되는 값으로 설정됩니다. 예를 들어 다음은 SYN와 Accpet 큐 크기를 1024로 지정합니다.

listen(sfd, 1024)

참고로 커널 4.3 이전에는 SYN 큐 크기가 다르게 설정되었습니다.

SYN 큐의 최대 크기는 net.ipv4.tcp_max_syn_backlog에 의해 정해졌었지만 이제는 아닙니다. 최근에는 net.core.somaxconn이 두 큐의 최대 크기를 지정합니다.

$ sysctl net.core.somaxconn
net.core.somaxconn = 16384

완벽한 backlog 값

위 내용을 이해했다면, 이상적인 backlog 파라미터 값에 대한 궁금증이 생길 수 있습니다.

그런데 답은 그때그때 달라요 입니다. 대부분의 소규모 TCP 서버의 경우 이 값은 그리 중요하지 않습니다. 예를 들어 Go언어는 backlog 값 변경을 지원하지 않고 128로 고정해 놓았습니다. 하지만 이 값을 더 크게 지정해야 할 이유들이 있습니다.

초당 들어오는 연결 수가 매우 많다면 잘 동작하는 애플리케이션이라도 SYN 큐는 많은 패킷을 저장해야 할 수 있습니다.
backlog 값은 SYN 큐 크기를 지정합니다. 즉, 이 값은 아직 처리되지 않은 ACK 패킷의 수이기도 합니다. 클라이언트와의 평균 왕복 시간이 크다면, 더 많은 패킷을 저장할 수 있어야 합니다. 많은 클라이언트가 서버에서 멀리 떨어져 있다면 (수백밀리초 이상) 이 값을 늘리는 편이 좋겠죠.
TCP_DEFER_ACCEPT 옵션은 소켓을 SYN_RECV상태로 더 오래 둘 수 있고 큐 크기에 영향을 미칩니다.

물론 backlog를 지나치게 크게 해도 안 좋습니다.

SYN 큐는 메모리를 소비합니다. SYN floods 시에는 공격 패킷을 저장하기 위해 리소스를 낭비할 필요가 없습니다. 각각의 struct inet_request_sock 엔트리는 커널 4.14에서 256bytes의 메모리를 차지합니다.

linux에서 SYN 큐를 들여다보기 위해서는 ss 커맨드를 이용해 SYN_RECV 소켓을 살피면 됩니다. 예를 들어 Cloudflare의 서버 중 하나에서는 다음과 같이 tcp/80 SYN 큐에 119개가, tcp/443에 78개가 쌓여 있음을 알 수 있습니다.

$ ss -n state syn-recv sport = :80 | wc -l
119
$ ss -n state syn-recv sport = :443 | wc -l
78

느린 애플리케이션

https://blog.cloudflare.com/syn-packet-handling-in-the-wild/

애플리케이션이 accept()를 충분히 빠르게 호출하지 못한다면 어떻게 될까요?

마법이 시작됩니다! Accept 큐가 꽉 차게 되면 (backlog+1 크기가 되면) 다음과 같은 일이 일어납니다.

SYN 큐로 추가될 수신 SYN 패킷이 버려짐
SYN 큐로 추가될 수신 ACK 패킷이 버려짐
TcpExtListenOverflows / LINUX_MIB_LISTENOVERFLOWS 카운터 증가
TcpExtListenDrops / LINUX_MIB_LISTENDROPS 카운터 증가

수신 패킷을 버려도 되는 주된 이유는 이것이 반작용 메커니즘이기 때문입니다. 달리 말하면 상대방은 느린 애플리케이션이 이미 복구되어 있기를 기대하며 SYN, ACK 패킷을 언젠가 다시 보내기 때문입니다.

이는 대부분의 서버에서 바람직한 행동입니다. 추가로 net.ipv4.tcp_abort_on_overflow를 지정할 수 있습니다만 권장되지 않습니다.

만약 여러분의 서버가 많은 연결을 처리해야 하고 accept() 성능 문제를 겪고 있다면 Nginx tuning/ Epoll work distribution과 a follow up showing useful System Tap scripts를 읽어 보세요.

Accept 큐 오버플로를 추적하려면 nstat 카운터를 보면 됩니다.

$ nstat -az TcpExtListenDrops
TcpExtListenDrops     49199     0.0

이 값은 전체 카운터입니다. 모든 애플리케이션이 별 문제 없어보이는데도 이 값이 증가하는 것이 종종 보인다면 좋은 상황은 아닐 것입니다. 가장 먼저 할 일은 ss로 Accept 큐 크기를 살펴보는 것입니다.

$ ss -plnt sport = :6443|cat
State   Recv-Q Send-Q  Local Address:Port  Peer Address:Port
LISTEN  0      1024                *:6443             *:*

Recv-Q 컬럼은 Accept 큐의 소켓 숫자, Send-Q는 backlog 값입니다. 이 경우에는 accept()가 안 된 소켓은 아직 없다는 걸 볼 수 있는데, 그래도 ListenDrops 카운터가 증가할 수 있습니다.

우리의 경우 애플리케이션이 아주 잠깐동안만 멈춘 것으로 보입니다. 아주 짧은 시간이라도 멈추기만 한다면 Accept 큐가 넘칠 충분한 이유가 될 것입니다. 순식간에 복구가 되었을 수도 있습니다. 이런 경우에 ss로 디버깅하는 것은 어렵습니다. 이런 경우를 대비해서 acceptq.stp SystemTap Script를 작성했는데, 커널을 후킹해서 버려지는 SYN 패킷을 출력합니다.

$ sudo stap -v acceptq.stp
time (us)        acceptq qmax  local addr    remote_addr
1495634198449075  1025   1024  0.0.0.0:6443  10.0.1.92:28585
1495634198449253  1025   1024  0.0.0.0:6443  10.0.1.92:50500
1495634198450062  1025   1024  0.0.0.0:6443  10.0.1.92:65434
...

이제 ListenDrops에 영향을 미치는 SYN 패킷을 정확하게 알 수 있습니다. 이 스크립트를 통해 어떤 애플리케이션이 연결을 버리고 있는지 쉽게 알 수 있습니다. 느린 애플리케이션 컽!

CC BY 2.0 image by [internets_diary](https://www.flickr.com/photos/16339684@N00/)

SYN Flood

https://blog.cloudflare.com/syn-packet-handling-in-the-wild/

Accept 큐 오버플로가 가능하다면 SYN 큐 오버플로도 가능하겠죠? 어떤 경우일까요?

바로 SYN Flood attacks입니다. 예전에는 SYN 큐를 위조된 SYN 패킷으로 넘치게 하는 것이 큰 문제였습니다. 1996년 이전에는 SYN 큐를 채우는 것만으로 대부분의 TCP 서버를 매우 적은 대역폭만으로 서비스 불능으로 만들 수 있었습니다.

https://en.wikipedia.org/wiki/SYN_flood

공격자는 ACK를 다시 보내지 않는 수많은 SYN 패킷을 보냅니다. 서버는 클라이언트의 연결을 받아들이기 위해 RAM 공간을 확보해서 대기하는데, ACK가 오지 않으니 RAM이 꽉 차게 되고, 정상적인 사용자의 SYN을 받지 못하게 됩니다.

이 문제의 해결책은 SYN 쿠키입니다. SYN 쿠키는 수신 SYN을 저장하지 않고 메모리 소비 없이 SYN+ACK를 만들 수 있는 방법입니다. SYN 쿠키는 정상적인 트래픽을 방해하지 않습니다.

SYN 쿠키와 TCP 타임스탬프

SYN 쿠키는 좋지만 부작용이 없는 것은 아닙니다. 주된 문제는 SYN 쿠키에 저장할 수 있는 데이터 크기가 작다는 것입니다. 구체적으로는 시퀀스 번호 32bits만이 ACK에 들어 있는데 다음과 같이 나눠서 사용됩니다.

+----------+--------+-------------------+
|  6 bits  | 2 bits |     24 bits       |
| t mod 32 |  MSS   | hash(ip, port, t) |
+----------+--------+-------------------+

MSS 값을 4가지만 정할 수 있게 되면서 리눅스는 상대방의 다른 TCP 옵션 파라미터를 알 수 없습니다. 타임스탬프, ECN, 선택적인 ACK(SACK), 윈도우 크기 변경 정보를 잃게 되어 TCP 세션 성능을 저하하는 요인이 됩니다.

다행히 리눅스에는 대책이 있습니다. 만약 TCP 타임스탬프가 켜져 있다면 이 32비트를 다른 용도로 재사용하여 이 문제를 해결할 수 있습니다.

+-----------+-------+-------+--------+
|  26 bits  | 1 bit | 1 bit | 4 bits |
| Timestamp |  ECN  | SACK  | WScale |
+-----------+-------+-------+--------+

tcp 타임스탬프는 기본적으로 이용 가능한 상태이기 때문에, sysctl로 확인해 보겠습니다.

$ sysctl net.ipv4.tcp_timestamps
net.ipv4.tcp_timestamps = 1

타임스탬프 기능이 활성화되어 있을 경우 타임스탬프 공간의 재활용이 가능하기 때문에 통신 간 대역폭이 조금 더 사용할 수 있습니다. 다만 타임스탬프의 유용성에 대해 많은 논의가 있습니다.

과거에 타임스탬프가 서버 가동 시간을 유출하는 경우가 있었습니다. (이게 얼마나 중요한 사항인지는 다른 문제지만) 이는 2016년 말에 수정되었습니다.
TCP 타임스탬프는 대역폭을 꽤 사용합니다 - 패킷당 12 바이트
SYN 쿠키가 동작하는 경우 TCP 타임스탬프는 TCP 연결의 성능 향상에 도움이 됩니다.

본문에서 Cloudflare는 TCP 타임스탬프를 꺼 두었다고 하네요.

Cloudflare 스케일의 SYN 홍수

https://blog.cloudflare.com/syn-packet-handling-in-the-wild/

SYN 쿠키는 위대한 발명이고 소규모의 SYN Flood 문제를 해결해 줍니다. 하지만 Cloudflare에서는 사용하지 않습니다. 암호학적으로 확인 가능한 수천의 SYN+ACK 패킷을 보내는 것은 괜찮지만, 대형 서비스인 Cloudflare는 초당 2억 패킷 이상의 공격을 받기 때문입니다. 이런 규모의 경우 SYN+ACK의 응답은 쓸모 없는 패킷만 양산할 뿐 큰 의미가 없다고 합니다.

그 대신 방화벽 단에서 악의적인 SYN 패킷을 차단하고, BPF에 컴파일된 p0f SYN 지문을 이용한다고 합니다. 또한 Gatebot이라는 자동화 시스템을 개발했다고 합니다. 자세한 내용은 여기에

발전하는 환경

리눅스의 SYN 패킷 처리 환경은 계속 발전하고 있습니다. 최근까지만 해도 SYN 쿠키는 오래된 커널 때문에 느렸습니다. 이 문제는 4.4에서 수정되었고 이제 커널은 초당 수백만의 SYN 쿠키를 보낼 수 있어서 대부분의 경우 SYN 홍수 문제는 실질적으로 해결되었습니다. 적절한 튜닝을 통해 정상적인 연결의 성능을 방해하지 않고 아주 귀찮은 홍수를 방어할 수 있습니다.

애플리케이션 성능도 많은 관심을 끌고 있습니다. SO_ATTACH_REUSEPORT_EBPF와 같은 아이디어는 네트워크 스택을 프로그래밍할 수 있는 새로운 계층을 제공합니다.

운영체제의 잘 바뀌지 않던 부분인 네트워킹 스택에 혁신과 새로운 아이디어가 도입되고 있다는 것은 좋은 일입니다.

끝으로

SYN에 대해 딥다이브 해 보았습니다. 생소한 개념이 많아 이해하기 어려운 부분도 많습니다만 3 way handshake의 기반에 대해 조금은 자세하게 알게 된 것 같습니다.

정리하면서 덧붙이는 과정에 잘못된 내용이 있을 수 있습니다. 제가 잘못 옮겼거나 추가한 부분이 있다면 꼭 말씀해 주세요! 열심히 찾아서 수정하겠습니다.

References

3 way handshake의 이해(번역)

Joonon — Sun, 7 Nov 2021 18:17:47 +0900

이 글(영문)을 정리해서 옮긴 글입니다.

오역이 있다면 댓글로 말씀해 주시면 감사하겠습니다.

THREE WAY HANDSHAKE이란 무엇인가?

Three-Way HandShake, 혹은 TCP 3-way handshake라고 부르는 이것은 TCP/IP 네트워크에서 client와 server 간의 연결 connection을 만들기 위해 사용되는 과정 process입니다.

실제 데이터 통신 프로세스가 시작되기 전에 클라이언트와 서버가 동기화/승인 패킷을 교환하는 3단계의 프로세스입니다.

이 프로세스는 두 단말이 동시에 TCP 소켓 연결을 초기화/협상/분리 initiate/negotiate/separate하는 데 도움이 되도록 설계되었습니다. 이는 또한 양방향으로 동시에 다수의 TCP 소켓 연결을 전송하는 것을 가능하게 합니다.

TCP message types

Message	Description
SYN	연결을 시작하고 설정하는 데 사용됩니다. 또한 장치 간의 시퀀스 번호를 동기화합니다.
ACK	상대방이 SYN을 받았는지 확인합니다.
SYN-ACK	로컬 장치의 SYN 메시지와 이전 패킷의 ACK입니다.
FIN	연결을 종료하는 데 사용됩니다.

TCP Three-Way Handshake Process

TCP 트래픽은 3-way handshake로 시작됩니다. 이 과정에서 클라이언트는 서버와의 통신 세션을 요청하여 대화를 시작해야 합니다.

첫 번째 단계에서 클라이언트는 서버와 연결을 설정합니다. SYN과 함께 *세그먼트 segment: TCP에서의 packet를 보내고, 시퀀스 번호를 서버에게 알립니다.
이 때, 클라이언트는 SYN_SENT 상태가 됩니다.
이 요청을 받는 서버는 CLOSED가 아닌 LISTEN상태로, 포트 서비스가 가능한 상태여야 합니다.
요청을 성공적으로 받은 서버는 클라이언트에게 요청을 수락한다는 ACK와 SYN flag가 설정된 SYN-ACK 패킷을 발송하고 클라이언트가 다시 ACK로 응답하기를 기다립니다.
이 때, 서버는 SYN_RECEIVED 상태가 됩니다.
마지막으로 클라이언트는 서버에게 ACK를 보내고, 실제 데이터 전송 프로세스를 시작하기 위한 안정적인 연결을 생성하게 됩니다.
이 때, 클라이언트와 서버 상태는 ESTABLISHED가 됩니다.

*segment: TCP에서 바이트 스트림을 그룹화한 것. 송신 TCP에서는 header를 붙여 segment를 만든 후 IP 계층으로 전달(capsulation)하고, 수신쪽은 header를 떼고 application으로 전달(decapsulation)한다. 세그먼트의 헤더 크기는 기본 20byte이고 옵션이 붙으면 최대 60byte까지 커진다.

Real-world Example

Host X는 TCP SYN 패킷을 보내는 것으로 연결을 시작합니다. 이 패킷은 Host X가 전송해야 하는 데이터에 대한 시작을 나타내는 랜덤한 시퀀스 번호 (예: 4321)가 포함되어 있습니다.
그 후 서버는 패킷을 수신하고 시퀀스 번호로 응답합니다. 응답에는 ACK, 즉 1이 증가한 Host X의 시퀀스 번호를 포함한 승인 번호가 포함됩니다.
Host X는 서버의 시퀀스 번호에서 1이 증가한 ACK를 보내 서버에게 응답합니다.

데이터 전송 프로세스가 끝나면 TCP는 두 단말의 연결을 자동으로 종료합니다.

Subnet mask, Subnetting

Joonon — Fri, 29 Oct 2021 01:38:02 +0900

서브넷의 탄생

앞서 공부했던 네트워크 클래스에서 알 수 있듯, 클래스 단위로 네트워크를 분류하면 비효율적이었습니다.

따라서 단말 수에 맞추어 효율적으로 사용할 수 있는 서브넷 Subnet이라는 개념이 등장하게 되었습니다.

서브넷 Subnet

서브넷 Subnet은 말 그대로 부분망을 뜻합니다. IP 네트워크를 논리적으로 세분화한 것입니다. 그리고 이 서브넷을 만들 때 쓰이는 것이 바로 서브넷 마스크입니다. 이 서브넷 마스크를 이용해 IP주소 체계의 Network ID와 Host ID를 분리합니다.

IP 주소는 IP 클래스에 의해 분리되는 Network Prefix와 Host Number로 분리됩니다. 서브넷 마스크에 의해 이루어지는 서브넷팅은 이 Host Number를 Subnet Number와 서브넷 안에서 식별되는 Host Number로 다시 분리합니다.

서브넷팅 Subnetting

하나의 네트워크를 둘, 혹은 여러 개의 서브 네트워크로 나눠서, 외부에서 해당 네트워크를 바라볼 시에는 단일 네트워크처럼 보이지만 내부에서 보면 여러 개의 네트워크로 만드는 것입니다.

서브넷팅을 통해 네트워크의 밀집을 완화하고, 네트워크의 성능을 향상시킵니다. 보안은 덤입니다.

FLSM (Fixed Length Subnet Mask)

고정된 크기의 Subnet-mask를 사용하는 방식으로, 각 서브넷의 크기는 동일합니다.

예를 들어 192.128.32.0/24라는 네트워크 주소 하나를 12개씩의 호스트가 있는 각각의 네트워크로 분할하려고 한다면, 어떻게 서브넷팅해야 할까요?

주어진 서브넷과 서브넷 마스크를 2진수로 바꿔서 AND 연산을 해 보겠습니다.

IP Address	11011010.10000000.00100000.00000000
subnet-mask	11111111.11111111.11111111.00000000
AND연산	11011010.10000000.00100000.00000000

여기서 서브넷 마스크의 비트 중 1로 표시된 부분(24개)는 모두 Network ID로 사용되었으므로, 0으로 표시된 나머지인 Host ID 부분만 사용가능합니다.

12개의 호스트(단말)에 IP를 할당하기 위한 비트의 최소값은 4개입니다. (2^4 = 16개의 Host range)
기존의 Host-ID 부분을 필요한 만큼인 4bit만큼 자릅니다.

따라서 호스트 부분의 4bit로 표현할 수 있는 수의 범위를 표로 나타내면 아래와 같이 되겠습니다.

총 16개의 서브넷으로 나누어집니다.

범위 안의 숫자 중 맨 앞의 IP는 각 서브넷의 네트워크 주소가 되고, 맨 뒤의 IP는 브로드캐스트 주소가 됩니다.
즉, 첫 번째 서브넷에서 사용 가능한 Host IP는 1 ~ 14의 14개가 됩니다. 이 범위를 서브넷으로 나타내면 192.168.32.0이 되고, subnet mask(prefix)는 4bit를 더 사용했으니 /24 => /28이 되었습니다.

따라서 192.168.32.0/28이라는 네트워크 주소로 해당 서브넷을 나타낼 수 있습니다.

VLSM (Variable Length Subnet Mask)

서브넷팅을 이해했다면 VLSM은 쉽습니다.

위와 같은 동일한 크기의 서브넷과 달리 큰 부서에는 더 많이, 작은 부서에는 더 적게 IP를 배분해야 하는 상황이 올 수가 있습니다.

네트워크 주소: 200.1.1.0/24
개발부: 100개의 단말
홍보부: 50개의 단말
축구부: 2개의 단말

위와 같은 조건이라면 FLSM을 한다면 가장 큰 크기인 개발부에 맞춰서 자르게 되고, 다른 부서에는 너무 많은 IP가 남게 되어 낭비가 됩니다. 이러한 경우를 피하기 위해 각 부서 별로 필요한 만큼만 잘라서 사용해 보겠습니다.

이와 같이 다양한 길이의 서브넷 마스크가 되겠습니다.

실생활에서 서브넷팅을 해 봅시다 (Youtube Channel: Sunny Classroom)

어느 날 매니저가 당신에게 까페를 위해 네트워크 세 개를 만들어 달라고 부탁했습니다. 하나는 사무실, 하나는 데스크와 창고, 하나는 공공 사용을 위한 용도입니다. 당신은 각각의 Network ID, subnet mask, Host ID Range, # of usable host IDs, Broadcast ID를 리스트로 만들어야 합니다.

주어진 네트워크 ID는 192.168.4.0/24입니다.

모든 그림은 유튜브의 Sunny Classroom에서 가져왔습니다. Thank you! 너무 좋은 영상이니 한 번씩 봐주세요!)

위 표를 보면 한 방에 이해할 수 있습니다.

서브넷은 1부터 시작해서 2씩 늘어나고, 호스트는 그 역입니다. 저희는 3개의 네트워크가 필요하니까...

서브넷 4개로 나눌 수 있는 /26 서브넷 마스크가 필요하겠네요.

서브넷 마스크 26에 의해 4개로 나뉘어진 리스트를 표로 보면 위와 같습니다.

제 컴퓨터로 해볼까요?

제 컴퓨터의 어댑터 IP입니다.

이를 네트워크로 표현하면 192.168.0.100/24가 되겠네요!

IP range는 192.168.0.0 ~ 192.168.0.255이고, 저는 그 중에 하나를 배정받은 것을 알 수 있습니다.

아래의 명령어 순서대로 쳐서 IP 주소를 새로 받아 보아도 범위는 바뀌지 않는 것을 확인했습니다!

ipconfig /release: 현재 DHCP 구성 해제 및 어댑터의 IP 주소 구성 제거

ipconfig /renew : DHCP 클라이언트 컴퓨터로 구성된 컴퓨터에서만 사용가능하며, 서버로부터 새로운 IP 주소 및 구성값을 받아옴

release와 renew를 단시간에 반복하니 같은 주소만 배정되는 것 또한 확인했습니다. 신기하네요

긴 글 읽어 주셔서 감사합니다. 잘못된 내용, 오타는 댓글로 알려주세요. 적극적으로 수정하겠습니다.

References

React font 적용 - otf file format: otf(x) opentype(o)

Joonon — Thu, 28 Oct 2021 12:55:25 +0900

로컬에 있는 폰트 파일을 가져다 쓰는 방식으로 적용해 보겠습니다.

브라우저 별로 otf, ttf, woff 등 다양한 형식의 폰트 파일이 필요합니다. 필요한 만큼 준비합니다.

font.css에는 아래와 같이 작성했습니다.

/*
  src: 사용할 폰트의 위치 및 형식
     Safari, Android, iOS => ttf
     Modern Browsers => woff
     IE6-IE8 => eot
  */
@font-face {
  font-family: 'Noto Sans KR';
  font-weight: 400;
  font-style: normal;
  src: url('./NotoSansKR-Medium.otf') format('opentype'),
    url('./NotoSansKR-Bold.woff') format('woff');
}

font-family에 원하는 이름을 지정합니다.

⭐format('otf '가 아니라 'opentype')!!!!!!

otf 파일에는 format에 'opentype'을 지정해 줘야 합니다. 다른 블로그에 'otf'로 되어 있는 곳이 많아서 꽤나 삽질했습니다.

이후, index.js에서 font.css를 import했습니다. 그리고 폰트가 필요한 컴포넌트에 아래와 같이 불러옵니다.

.formHeader {
    /* font-weight: bold; */
    font-family: 'Noto Sans KR';
}

적용 전

적용 후

잘 적용되는 모습입니다.

Network Class

Joonon — Thu, 28 Oct 2021 00:24:24 +0900

클래스 도입 이전

원래 32Bit IPv4 주소는 호스트가 연결되어 있는 특정 네트워크를 가리키는 단순한 8비트의 네트워크 영역과 해당 네트워크 내에서 호스트의 주소를 가리키는 나머지 영역으로 단순하게 구분되어 있었습니다. 참고로 이 형태는 랜 도입 이전에 정해졌는데, 이는 미 국방성의 ARPANET - 최초의 네트워크과 같은 적은 수의 대규모 네트워크밖에 없었습니다.

ARPANET은 대규모 연구소나 군, 대학에서만 사용하던 패킷 스위칭 기반 통신 방식입니다.

1982년 프로토타입 인터넷 지도입니다.

클래스의 등장

IP 주소의 총 개수: 4,294,967,296

계산 방법: 256 _ 256 _ 256 * 256

클래스는 IP 주소를 네트워크 영역과 호스트 영역으로 나누는 방법이자 약속입니다.

클래스는 크게 5가지 (A, B, C, D, E) 클래스로 나뉩니다. 네트워크 크기에 따른 구분을 위해 클래스를 나눴습니다. 하나의 네트워크에서 몇 개의 호스트 IP를 가질 수 있냐는 차이가 있습니다.

A,B,C를 알면 됩니다. D,E는 멀티캐스트용, 연구용으로 사용합니다.

A 클래스

Network: 8bit

Host: 24bit

출처: https://wonit.tistory.com/554

A Class는 하나의 네트워크가 가질 수 있는 호스트 수가 제일 많기 때문에 대규모 네트워크 집단에서 사용했습니다.

A클래스에서 첫 번째 옥텟 - 8bit은 네트워크 부분을 나타내고 나머지 부분 - 24 bit은 호스트 부분입니다. 초기의 미국 대형 기업들이 선점해갔습니다.

IP주소를 32자리 2진수로 표현했을 때, 맨 앞자리 수가 항상 0인 경우가 바로 A클래스입니다.
즉 0xxx xxxx.xxxx xxxx. xxxx xxxx. xxxx xxxx과 같은 형태입니다. 가질 수 있는 범위로는
0000 0000. 0000. 0000. 0000 0000. 0000 0000 ~ 0111 1111. 1111 1111. 1111 1111. 1111 1111이고 이를 십진수로 표현하면 0.0.0.0 ~ 127.255.255.255입니다.

A클래스에서 네트워크 주소는 가장 작은 네트워크인 1.0.0.0과 가장 큰 네트워크인 126.0.0.0까지로 규정되어 있으며(0xxx xxxx에서 x가 가질 수 있는 경우의 수가 네트워크 범위입니다. 여기서 127은 제외되는 것이 약속입니다), 참고로 네트워크에서 0은 호스트 부분을 뜻합니다.
따라서 호스트 주소가 가질 수 있는 개수는 2^24 -2(모든 자리 값이 0일 경우 네트워크 주소, 모두 1일경우 브로드캐스트 주소로 사용하기 때문에)개가 됩니다.

예를 들어 13.0.0.0 네트워크 주소를 할당 받았다고 치겠습니다. 여기서 13은 네트워크 부분이고, 나머지 0.0.0에 호스트 IP를 할당할 수 있습니다. 십진수 0.0.0은 2진수로 표현하면 총 24개의 2진수로 표현이 가능하고 이는 곧 2^24개의 호스트 IP를 가질 수 있음을 의미합니다.

십진수로 나타내면 13.0.0.0 ~ 13.255.255.255입니다. 여기서 13.0.0.0은 네트워크 주소, 13.255.255.255는 브로드캐스트 주소로 사용되고 그 사잇값이 호스트 IP로 사용할 수 있는 주소가 되겠습니다.

B 클래스

Network: 16bit

Host: 16bit

출처: https://wonit.tistory.com/554

중규모의 네트워크 집단에서 사용했습니다.

B클래스는 반드시 10으로 시작합니다. 2진수로 표현하면 10xx xxxx. xxxx xxxx. xxxx xxxx. xxxx xxxx입니다.
B클래스의 IP 범위는 128.0.0.0 ~ 191.255.255.255이고 네트워크 범위는 10xx xxxx. xxxx xxxx에서 x들이 가질 수 있는 경우의 수인 2^14개입니다. 다르게 계산해 보면 첫 번째 옥텟의 범위는 128 ~ 191이고, 두 번째 옥텟은 8bit (256) 이므로 2^6 * 2^8 = 2^14(16384)개가 되겠습니다. 호스트 주소 범위는 16bit로 2^16 - 2개입니다.

C클래스

Network: 24bit

Host: 8bit

출처: https://wonit.tistory.com/554

소규모의 네트워크 집단에서 사용했습니다.

C클래스는 반드시 110으로 시작합니다. 첫 번째 옥텟은 192 ~ 223으로 2^5, 나머지 2개의 옥텟은 8bit이므로 32 _ 256 _ 256 = 2,097,152개가 C클래스의 총 네트워크 수입니다.

D, E클래스

특수한 목적(실험, 연구, 개발)으로 이미 예약되어 있는 구간입니다.

출처: https://wonit.tistory.com/554

중요) 클래스 계산 간단하게 하는 방법

클래스 별로 첫 번째 옥텟의 범위가 정해져 있습니다. A ~ E로 이동할수록 앞에서부터 1비트씩 채워진다고 기억하면 편합니다.

A클래스는 0000 0000 ~ 0111 1111 (0 ~ 127)
B클래스는 1000 0000 ~ 1011 1111 (128 ~ 191)
C클래스는 1100 0000 ~ 1101 1111 (192 ~ 223)
D클래스는 1110 0000 ~ 1110 1111 (224 ~ 239)
E클래스는 1111 0000 ~ 1111 0111 (240 ~ 255)

각 클래스별 최상위 비트 ~ 다음 클래스 최상위 비트 까지의 숫자로 나타내면 아래와 같습니다.

A클래스는 00000000.00000000.00000000.00000000
B클래스는 10000000.00000000.00000000.00000000 (128)
C클래스는 11000000.00000000.00000000.00000000 (192)
D클래스는 11100000.00000000.00000000.00000000 (224)
E클래스는 11110000.00000000.00000000.00000000 (240)

즉 A클래스가 움직일 수 있는 범위는 이진수로 보면 00000000 ~ 10000000 입니다. 00000001 ~ 01111111 까지라고 표현할 수도 있습니다. 즉 0 ~ 127로 클래스(네트워크)의 수는 128개입니다.

A와 B 사이의 127은 그럼 왜 사용하지 못하나요?

자기 자신을 가리키기 위한 목적으로 쓰기 위해 예약된 IP 주소이기 때문입니다.
IPv4의 경우 127.0.0.0 ~ 127.255.255.255이며, 보통 127.0.0.1을 사용합니다.

루프백용으로 넓은 대역을 할당하기에는 아까웠는지 IPv6는 ::1/128, 딱 한 개의 주소만 사용합니다. 보통 시스템에서는 /etc/hosts 파일 등에 localhost를 127.0.0.1로 연결시켜 두어서, 호스트 이름에 localhost를 입력하면 DNS를 타지 않고 바로 로컬로 연결됩니다.

IP 클래스의 비효율성

대부분의 사이트는 C 클래스를 사용하기엔 너무 커서 B클래스를 할당받았지만 인터넷의 빠른 발전으로 클래스 B의 주소는 급속도로 소진되었습니다.

처음 만들었을 때에는 40억개면 충분하겠다고 생각했지만 지금 기준에는 너무나도 모자라기 때문에 한정된 자원을 체계적으로 잘 나눠 쓰기 위해 고안된 것이 서브넷 마스크(subnet mask)입니다. 1993년, 이 서브넷 마스크를 사용한 CIDR의 등장과 함께 네트워크 클래스는 폐기되었습니다.

연습문제 풀어보기

다음 IP를 보고 클래스, 네트워크 부분, 호스트 부분 맞춰 보세요. IP를 클릭하면 정답이 펼쳐집니다.

10.3.4.3

클래스: A
네트워크 부분: 10.0.0.0
호스트 부분:3.4.3

132.12.11.4

클래스: B
네트워크 부분: 132.12.0.0
호스트 부분:11.4

203.10.1.1

클래스: C
네트워크 부분: 203.10.1.0
호스트 부분:1

192.12.100.2

클래스: C
네트워크 부분: 192.12.100.0
호스트 부분:2

261.124.4.6

존재할 수 없는 IP 주소입니다.

References

Nginx, SSL(Letsencrypt)의 설치 및 설정

Joonon — Tue, 5 Oct 2021 13:13:56 +0900

nginx 설치

sudo apt-get install nginx

nginx 서버 블록 설정

nginx 설정 파일 수정

sudo vi /etc/nginx/nginx.conf

http {} 블록 안에 아래의 구문 추가

include /etc/nginx/sites-enabled/*.conf; // sites-enabled 디렉토리에서 서버 블록을 찾도록 지시
server_names_hash_bucket_size 64; // 도메인이름 분석하는데 할당되는 메모리 양

서버 블록 파일 만들기 및 설명

sudo vi /etc/nginx/sites-available/j5d202.p.ssafy.io.conf

기본 포트인 80을 listen하도록 합니다. 기본 포트를 변경하려면 conf/nginx.conf의 listen을 수정합니다.
HTTPS 연결을 위해 리다이렉트 해줍니다. 이렇게 하면 443 port로 리다이렉트되어, server_name에 설정해 둔 domain에 해당하는 곳으로 요청하게 됩니다.
장고 관련 처리는 /api/v1 으로 보낼 것입니다. proxy_pass로는 WSGI 중 하나인 gunicorn의 소켓을 사용하여 처리했으며, 이는 ubuntu에서 localhost로 간주됩니다.
- (중요!!) 따라서 django의 settings.py의 ALLOWED_HOST에 localhost가 있어야 합니다!! 그렇지 않으면 에러가 발생합니다.
이로서 클라이언트 측에는 포트 번호 및 정확한 경로를 보여주지 않으면서 올바르게 리다이렉트 할 수 있게 되었습니다.

server {
        listen 443 ssl;
        listen [::]:443 ssl;

        server_name j5d202.p.ssafy.io www.j5d202.p.ssafy.io;

        ssl_certificate /home/ubuntu/docker_volume/fullchain.pem;
        ssl_certificate_key /home/ubuntu/docker_volume/privkey.pem;

        root /home/ubuntu/dist;

        index index.html;

        location / {
                try_files $uri $uri/ /index.html;
        }

        location /api/v1 {
                proxy_pass http://unix:/home/ubuntu/Together/backend/gunicorn.sock;
                proxy_redirect off;
                charset utf-8;

                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded_proto $scheme;
                proxy_set_header X-NginX-Proxy true;
        }
}
server {
        listen 80;
        listen [::]:80;

        server_name j5d202.p.ssafy.io www.j5d202.p.ssafy.io;

        return 301 https://$server_name$request_uri;
        index index.html index.htm;
}

서버 블록 파일 활성화

이제 서버 블록 파일을 만들었으니 nginx가 방문자에게 파일을 제공할 수 있도록 활성화합니다.

이를 위해 sites-enabled 디렉토리에 각 서버 블록에 대한 심볼릭 링크를 생성합니다.

sudo ln -s /etc/nginx/sites-available/j5d202.p.ssafy.io.conf /etc/nginx/sites-enabled/j5d202.p.ssafy.io.conf

nginx 관련 명령어

$ sudo apt install nginx
$ sudo systemctl start nginx
$ sudo systemctl stop nginx # nginx 서비스 중단
$ sudo systemctl reload nginx # nginx 설정 리로드
$ sudo nginx -t # nginx 설정 체크 (test)

SSL 설치 및 설정

letsencrypt 설치

sudo apt-get install letsencrypt

nginx 중지 (도커로 띄워놓지 않은 상태입니다)

sudo systemctl stop nginx

인증서 발급

sudo letsencrypt certonly --standalone -d j5d202.p.ssafy.io

정상적으로 발급되었을 경우 /etc/letsencrypt/live/{도메인 네임}에 키 값을 얻을 수 있습니다.

SSL 옮기기

$ sudo cp /etc/letsencrypt/live/j5d202.p.ssafy.io/fullchain.pem <사용할 폴더>
$ sudo cp /etc/letsencrypt/live/j5d202.p.ssafy.io/privkey.pem <사용할 폴더>

nginx conf 수정

server {
        listen 443 ssl;
        listen [::]:443 ssl;

        server_name j5d202.p.ssafy.io www.j5d202.p.ssafy.io;

        ssl_certificate <사용할 폴더 path>/fullchain.pem
        ssl_certificate_key <사용할 폴더 path>/privkey.pem

        root /home/ubuntu/dist;
        index index.html;

        location / {
                try_files $uri $uri/ /index.html;
        }

        location /account {
                proxy_pass https://localhost:8080;
                proxy_redirect off;
                charset utf-8;

                proxy_set_header   X-Real-IP $remote_addr;
                proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header   X-Forwarded_proto $scheme;
                proxy_set_header   X-NginX-Proxy true;
        }
        location /accounts {
                proxy_pass https://localhost:8080;
                proxy_redirect off;
                charset utf-8;

                proxy_set_header   X-Real-IP $remote_addr;
                proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header   X-Forwarded_proto $scheme;
                proxy_set_header   X-NginX-Proxy true;
        }
}
server {
        listen 80;
        listen [::]:80;

        server_name j5d202.p.ssafy.io www.j5d202.p.ssafy.io;
        return 301 https://$server_name$request_uri;

        index index.html index.htm;
}

nginx 시작

sudo systemctl start nginx

HTTPS 연결 성공

References

how-to-set-up-nginx-server-blocks

MTU와 MSS

Joonon — Sun, 3 Oct 2021 21:48:15 +0900

MTU (Maximum Transmission Unit)

MTU란 OSI model의 3계층, Network Layer에서 처리할 수 있는 가장 큰 데이터 블록입니다. 네트워크 인터페이스에서 세그멘트 없이 보낼 수 있는 최대 데이터그램 크기 값입니다.

우리가 주로 사용하는 이더넷의 MTU 값은 일반적으로 1500 바이트이며, 옛날에 모뎀을 통해 접속하던 PPPoE 연결은 1492 바이트였다고 합니다. Gigabit MTU와 같은 Jumbo Frames은 1500바이트 이상의 페이로드를 지닌 이더넷 프레임으로, 최대 9000바이트의 페이로드까지 지원합니다.

MSS (Maximum Segment Size)

MSS는 TCP 상에서의 전송할 수 있는 사용자 데이터의 최대 크기를 의미합니다. MSS는 기본적으로 MTU 값에 기인합니다. 예를 들어 Ethernet일 경우, MTU 1500에 IP 헤더크기 (최소 20byte), TCP 헤더 크기 (최소 20byte)를 제외한 1460이 MSS 값이 됩니다. RFC1323에서 정의한 타임스탬프 옵션이 확장되어 사용되면 12바이트가 늘어 1448 바이트가 됩니다.

TCP 프로토콜 연결 시 SYN 패킷을 보낼 때 MSS를 포함하게 됩니다. SYN 패킷을 들여다 보면

0x0204 0x05B4

출처: PacketInside.com

값을 볼 수 있습니다. 02는 MSS 옵션의 시작점을 뜻하고 04는 옵션의 크기(4바이트), 0x05B4는 크기를 뜻합니다. 05b4 값이 1460바이트입니다. 이렇게 MSS 크기를 전송하면 받는 측에서도 어떤 크기로 전송해야 할지 알고 준비하게 됩니다.

Where does this limit come from?

3계층의 한계는 2계층에서 비롯됩니다. 2계층은 frame을 사용하는 Data Link Layer로, 각 프레임은 최대 크기에 한계가 있습니다. 이더넷 표준을 예로 들면, 최대 프레임 사이즈가 1518 bytes입니다. 이더넷의 헤더는 18 bytes 이므로, 나머지 1500를 패킷으로 사용할 수 있게 됩니다. 그러므로 이더넷 패킷 MTU는 1500 바이트가 됩니다.

Fragmentation (IP 단편화, 분할)

호스트는 자체 네트워크의 MTU는 확실히 알고 있습니다. 그러나 더 높은 경로에 있는 링크의 MTU를 알 수 있는 방법은 없습니다.

예를 들어 컴퓨터의 NIC Network Interface Controller의 MTU는 1500인데, WAN에 연결하는 MTU는 1400인 경우가 있습니다. 컴퓨터의 MTU가 더 커서 전송하지 못하는 상황이 됩니다.

해결책은 단편화입니다. 패킷이 MTU보다 크면 장치(주로 라우터)가 패킷을 작은 fragments들로 나눕니다.

각각의 fragments들은 여전히 패킷이지만, 원래의 것보다 크기만 약간 작을 뿐입니다. 패킷들은 목적지로 잘 움직입니다. 목적지의 기기는 조각들을 다시 모아서 원래의 패킷으로 재조립하고 정상적으로 처리합니다.

듣기만 하면 기가 막힌 솔루션인데 하나 단점이 있습니다. 먼저 각 조각에 중복된 IP 헤더 때문에 원래의 크기보다 더 많은 트래픽이 전송되게 됩니다. 즉, 효율성이 낮습니다.

또한 패킷을 나누는 라우터와 재조립하는 기기에 처리를 위한 오버헤드를 추가합니다. 만약 한 조각이라도 누락되거나 손상되면? 다시 전체 패킷을 보내야 합니다.

방화벽 또한 조각들과 관련해 문제를 일으킬 수 있습니다. 단편화는 가급적 피해야 하겠습니다.

단편화 방지

TCP MSS
- TCP의 MSS 크기를 낮춥니다. 즉, 페이로드를 조절합니다.
PMTUD

PMTUD

PMTUD란 목적지로 가는 경로상에 존재하는 링크들 중 MTU값이 가장 작은 링크의 MTU 값을 확인하는 과정을 말합니다. IPv6에서 패킷의 분할을 위해 사용합니다.

IPv6에서는 오직 출발지 장비만이 패킷을 분할할 수 있도록 규정해 놓았습니다. 그 이유는 IPv4에서 목적지로 가는 경로상의 중간 라우터들이 무분별한 분할을 수행하며 발생했던 라우팅 속도 저하와 관련된 문제 때문입니다.

IPv6에서는 위 문제를 해결하기 위해 출발지에서만 분할이 가능하도록 해 두었습니다.

PMTUD의 동작

위와 같이 출발지 장비가 패킷을 알맞게 분해하기 위해서는 PMTUD 과정을 반드시 거쳐야 합니다.

호스트 A가 먼저 패킷을 분할해서 전송
라우터 A가 패킷을 받고 나서 링크 B의 MTU 크기를 확인. 받은 패킷의 크기가 링크 B의 MTU보다 크면 호스트 A에 패킷 크기 초과 메시지를 재전송
반복
3~6: 더 이상 패킷 크기 초과 메시지를 받지 않게 되면 가장 작은 MTU인 500바이트로 분할하여 전송한다. 이후 호스트 A는 주기적으로 다시 자신의 링크 MTU 크기에 맞게 패킷을 분할하여 전송하며, 경로상의 최소 MTU 값의 변동을 확인한다.

Each Application's MTU

윈도우 MTU 확인

netsh 명령어로 인터페이스 정보를 확인할 수 있습니다.

그리고 ping 명령어로도 알아 볼 수 있습니다. -ㅣ로 데이터 크기를 지정할 수 있는데, MTU 크기 값 이상이 되면 Fragment(단편) 메시지를 볼 수 있게 되어 이걸로 MTU를 알아볼 수 있게 됩니다.

1472 크기를 지정하니 잘 보내고 응답도 잘 받습니다.

왜 1472바이트를 보냈나요?
- 위에서 보았듯 인터페이스에 설정된 값은 1500바이트 입니다. 여기서 IP 헤더가 20바이트이고 ICMP(ping에 사용되는 프로토콜) 헤더 가 8바이트 (TYPE, CODE, CHECKSUM, DATA)입니다. 즉 1500 - 28 = 1472 바이트가 최대가 되는 것입니다.
- ICMP는 IP 데이터그램을 사용합니다.

그럼 이번엔 1472보다 1 큰 1473 바이트를 보내 보겠습니다.

Fragment가 필요하다고 나타납니다. 한번에 전송할 수 있는 값이 1472 바이트가 맞네요.

방화벽으로 Ping의 허용, 블록 (ICMP Echo Requests)

개인적으로 배포한 블로그가 아닌, Tistory, Naver같은 상용 서비스에 핑을 보내 보았습니다.

오, 역시 막히네요. 쓸데없는 핑을 다 받아 주면 리소스가 낭비될 테니 당연한 일입니다.

방화벽으로 핑을 허용하고 막는 방법에 대한 글은 링크에 있습니다.

긴 글 읽어 주셔서 감사합니다. 잘못된 내용, 오타는 댓글로 알려주세요. 적극적으로 수정하겠습니다.

References

[Programmers] 위클리 챌린지 8주차_최소직사각형

Joonon — Wed, 29 Sep 2021 22:46:07 +0900

비교적 간단한 문제입니다. 원 라인 코딩으로도 바꿔 보았습니다.

def solution(sizes):
    h, l = 0, 0
    for size in sizes:
        if min(size) > l:
            l = min(size)
        if max(size) > h:
            h = max(size)
    return l*h

# 위 로직을 한줄로
def solution(sizes):
    return max(max(x) for x in sizes) * max(min(x) for x in sizes)

print(solution([[60, 50], [30, 70], [60, 30], [80, 40]]))

[Programmers] 신규 아이디 추천

Joonon — Wed, 22 Sep 2021 13:55:43 +0900

차근차근 풀면 되는 문자열 문제입니다. indexing 전에 빈 문자열이 되었는지 체크하는 것을 잊지 말도록 합시다.

import re
def solution(new_id):
    tmp = new_id
    # 1
    tmp = tmp.lower()
    # 2
    tmp = re.sub("[^a-z0-9_\-.]", "", tmp)
    # 3
    tmp = re.sub("\.{2,}", ".", tmp)
    # 4
    if tmp == '':
        tmp = 'a'
    if tmp[0] == '.':
        tmp = tmp[1:]
    if tmp == '':
        tmp = 'a'
    if tmp[-1] == '.':
        tmp = tmp[:len(tmp)-1]
    # 5
    if tmp == '':
        tmp = 'a'

    # 6
    if len(tmp) >= 16:
        tmp = tmp[:15]
    if tmp[-1] == '.':
        tmp = tmp[:len(tmp)-1]

    #7
    if len(tmp) <= 2:
        tmp += tmp[-1]*(3-len(tmp))
    return tmp

# 반례
solution("=.=")

[BOJ] 14503 - 로봇 청소기

Joonon — Sat, 18 Sep 2021 14:28:02 +0900

구현 문제. 차근차근 구현하면 어렵지 않다.

스택을 사용할 필요는 없는데 머리에서 그려보기 편해서 써봤다.

from sys import stdin

R, C = map(int, stdin.readline().split())
r, c, d = map(int, stdin.readline().split())
arr = [list(map(int, stdin.readline().split())) for x in range(R)]
visited = [[0]*C for x in range(R)]

# 'left', 'bottom', 'right', 'up'
head = [(0,-1), (1,0), (0,1), (-1,0)]

# 바라보는 방향 init
idx_head = 3 - d

result = 0

stack = [(r, c)]
while stack:
    cr, cc = stack.pop()

    if not visited[cr][cc]:
        visited[cr][cc] = 1
        result += 1
    able = False
    # 방향전환으로 갈 수 있는 방향 찾기
    # 왼쪽부터 가야 하므로 방향부터 옮기고 찾기
    for i in range(4):
        idx_head = (idx_head+1)%4
        # 갈 수 있으면 전진 (스택에 추가)
        nr, nc = cr + head[idx_head][0], cc + head[idx_head][1]
        if 0 <= nr < R and 0 <= nc < C and not visited[nr][nc] and not arr[nr][nc]:
            stack.append((nr, nc))
            able = True
            break

    # for문을 빠져나왔다는건 다 돌았는데도 갈데가 없다는 것
    # 후진 가능하면 후진
    br, bc = cr - head[idx_head][0], cc - head[idx_head][1]
    if not able:
        if 0 <= br < R and 0 <= bc < C and not arr[br][bc]:
            stack.append((br, bc))
print(result)