개발을 진행하던 중, 버튼 안에 이미지를 넣고 싶은데 다음과 같은 문제가 발생했다.

이 문제는 이전에 해결한 적이 있었는데 어떻게 했는지 기억이 나질 않았다.

앞으로 비슷한 상황을 마주했을 때 찾아보기 위해 정리한다!!

이미지 크기 조정하기

이미지 크기를 조정하는 방법은 먼저 extension을 추가해줘야 한다.

import UIKit

extension UIImage {
    func resize(targetSize: CGSize) -> UIImage? {
        let rect = CGRect(origin: .zero, size: targetSize)
        UIGraphicsBeginImageContextWithOptions(targetSize, false, 0.0)
        self.draw(in: rect)
        let resizedImage = UIGraphicsGetImageFromCurrentImageContext()
        UIGraphicsEndImageContext()
        return resizedImage
    }
}

이렇게 UIImage 익스텐션을 만들어준다.

그리고, 원하는 버튼을 세팅하는 부분에서 다음과 같이 사용하면 된다.

private let settingButton = UIButton().then {
    let imageSize = CGSize(width: 100, height: 100) // 1
    let resizedImage = UIImage(systemName: "gearshape")?.resize(targetSize: imageSize) // 2
    $0.imageView?.contentMode = .scaleToFill // 3
    $0.setImage(resizedImage, for: .normal) // 4
}

(나는 then을 사용하였다.)

1. 먼저, 이미지 크기를 CGSize를 사용하여 설정해준다. 위 코드에서는 너비와 높이 모두 100으로 설정되었다.

2. 그리고, 크기를 조정하고자 하는 이미지를 가져와 아까 만들어둔 extension을 사용해준다.

3. 이제 이미지뷰의 contentMode를 scaleToFill로 설정해 이미지가 뷰에 가득 차도록 한다.

4. UIButton에 있는 setImage함수를 사용해 이전에 크기를 조정한 이미지를 가져와준다.

이렇게 하면, UIButton 안에 원하는 이미지를 가져오고, 그 이미지 크기를 마음대로 조정할 수 있다.

개발을 하던 중, 테이블 뷰 아래 자꾸 다음과 같은 구분선이 생기는 걸 확인했다.

limitTableView.separatorStyle = .none

그럴 때는 이렇게 구분 스타일을 .none으로 바꿔주면 된다.

이제 이렇게 구분선이 사라진 걸 확인할 수 있다 !

2.1 네트워크 애플리케이션의 원리

Creating a network app

• software 개발자 관점에서는 네트워크 구조가 고정되어 있다. 하지만, application 구조는 개발자가 설계하며, 여러 종단 시스템에서 어떻게 조직되어야 하는지를 알려준다.
• 이러한 application 구조는 크게 2가지로 나뉜다.
  • Client - server 구조
  • P2P 구조

Client-server paradigm

• Server
  • 항상 동작하고 있는 서버가 존재하고, Client라는 다른 호스트들로부터 서비스 요청을 받는다.
  • 서버는 잘 알려진 고정 IP 주소를 갖는다. (permanent IP address - not change)
  • 서버가 클라이언트로부터 오는 모든 요청에 더 응답하는 것이 불가능할 때
    • 많은 수의 호스트를 갖춘 data center가 강력한 가상의 서버를 생성하는 역할로 사용된다.
    • 보통 10만개 정도의 서버를 갖추고 있다.
• Clients
  • 필요할 때 connect 한다.
  • may be intermittently connected (간접적으로, 가끔식 연결된다)
  • dynamic IP address를 갖는다.
  • Client끼리는 직접 통신하지 않는다.

P2P 구조

• Client와 server 둘 다의 responsibility를 갖는다.
• 항상 켜져있는 서버에 의존하지 않는다.
• 임의의(arbitrary) end system들은 직접 소통한다.
  • 즉, peer라는 간헐적으로 연결된 호스트 쌍이 서로 직접 통신하게 한다.
• peer는 우리가 흔히 알고 있는 Client(laptop 같은 것들)
• **Self scalability(자가확장성)**를 갖는다.
  • 즉, 사용자가 많아질수록 네트워크에 부담이 커지는 것이 아니라, 오히려 서로 도와서 네트워크의 효율성이 높아진다.
  • 예를 들어, 파일 공유 application에서는 각 peer들이 파일을 요구하여 작업 부하가 생기지만, 각 Peer들은 파일을 다른 Peer들에게 분배하여 시스템에 서비스 능력을 갖춘다.
• data center 등이 필요 없으므로 비용이 효율적이다.

👩🏻‍💻 2.1.2 프로세스 간 통신

실제 통신하는 것은 프로그램이 아니라, 실행되고 있는 프로그램인 process이다.

• 같은 host 범위 내에서, 두개의 process들은 IPC를 사용해 communication 한다.
  • Inter-process-communication : 두 개 이상의 프로세스가 데이터를 주고받는 방법
• 다른 host 범위 내에서는 exchanging messages를 통해 소통한다.
• 2개의 종단 시스템에서 프로세스는 컴퓨터 네트워크를 통한 메시지 교환으로 서로 통신한다.
• P2P 구조에서처럼 Client도 서버 프로세스가 될 수 있고, 서버도 client process가 될 수 있다.
• 송신 프로세스 : 메시지를 만들어서 보냄
• 수신 프로세스 : 메시지를 받고 역으로 메시지를 보냄으로써 응답

Client, Server process

• client process : process that initiates communication
  • 요청을 보내는 쪽의 프로세스
• server process : process that waits to be contacted
  • 요청을 받는 쪽의 프로세스

Socket

process는 socket을 통해 네트워크로 메시지를 보내고 받는다. (문 같은 개념)

• 호스트의 application 계층과 transport 계층간의 인터페이스이다.
• 애플리케이션 개발자는 소켓의 application 계층에 대한 모든 통제권을 갖지만, 소켓의 transport 계층에 대한 통제권은 거의 갖지 못한다.
  • transport protocol을 선택
  • 최대 버퍼와 최대 세그먼트 크기 같은 약간의 매개변수 설정
• sending process shoves message out door - 전송 프로세스는 메시지를 밖으로 밀어낸다.
• Application과 network 사이의 API라고도 한다.

Addressing processes

프로세스가 수행되고 있는 다른 패킷으로 프로세스를 보내기 위해서는 수신 프로세스가 주소를 갖고 있어야 한다. 수신 프로세스를 식별하기 위해서는 두 가지 정보가 필요하다.

Identifier는 IP주소와 port number를 갖는다.

1. 호스트의 주소 즉, IP 주소가 필요하다.
   1. IP 주소가 identifier가 된다.
2. 호스트 내의 수신 프로세스를 명시하는 식별자. 즉 port 번호가 필요하다.
   1. 이 port 번호로 내 process를 특정할 수 있다.
   2. 같은 IP 주소를 가진 여러 application이나 process가 동시에 수행될 수 있기 때문에 port 번호로 구분한다.

• IP를 통해 적절한 computer를 찾는다.

👩🏻‍💻 2.1.3 An Application-layer protocol defines

application 개발자는 소켓의 application 계층에 대한 모든 통제권을 갖지만, 소켓의 transport 계층에 대한 통제권은 거의 갖지 못한다. 즉, 여기에서는 그 중 애플리케이션이 어떤 transport service를 이용할 수 있는지에 대한 내용이다.

1. Data integrity
   1. 손실되지 않는 data를 전송
2. throughput
   1. 다른 session들이 network 경로를 따라 대역폭을 공유하고, 이 세션들이 생겼다 없어졌다 하기 때문에 가능한 처리율은 시간에 따라 변한다. 이는 어느 명시된 속도에서 보장된 가용 처리율을 제공한다.
   2. 이러한 처리율 요구사항 여부를 기준으로 두 가지로 나뉜다.
      1. effective app : 처리율 요구사항이 있는 민감 application
      2. elastic app : 탄력적 application. 처리율 요구사항이 없다.
3. timing
   1. 예를 들어, 송신기가 socket으로 내보내는 모든 bit가 수신자의 socket에 100ms 내에 도착하게 할 수 있다. 주로 실시간 application에서 사용한다.
4. security
   1. data를 암호화 할 수 있다.

Internet transport protocols services

인터넷 전송 프로토콜이 제공하는 서비스

1. TCP 서비스
2. UDP 서비스

TCP service

• reliable transport
• 서로 전송 제어 정보를 교환하게 한다.

UDP service

• unreliable data transefer
• hand shaking 과정이 없고, 데이터가 전달되는 것을 보장하지 않는다.

TCP vs. UDP

• TCP가 UDP보다 더 유용하지만, UDP는 더 빠르다.
• 둘 다 처리율 혹은 시간 보장 서비스를 제공하지 않는다.
  • 그래서 시간 민감 애플리케이션 같은 경우, 이러한 처리율 및 시간 지연에 잘 대처할 수 있도록 설계되어 있다.

👩🏻‍💻 2.1.5 Application layer: Protocol

다른 종단 시스템에서 실행되는 애플리케이션의 프로세스가 서로 메시지 보내는 방법을 정의한다.

• 교환 메시지의 타입
• 여러 메시지 타입의 문법(syntax)
• 필드의 의미, 즉 필드에 있는 정보의 의미(semantics)
• 언제, 어떻게 프로세스가 메시지를 전송하고 메시지에 응답 하는지를 결정하는 규칙

네트워크의 프로토콜 계층 구조와 서비스 모델, 인터넷 프로토콜 스택과 OSI 모델, 캡슐화, 역캡슐화

🍪 Why layering?

계층구조는 어떤 한 계층의 구현이 변하더라도 시스템의 나머지 부분은 변하지 않는다.
하지만, layering의 단점은 overhead가 발생할 수 있다는 것이다. duplicate할 때 overhead가 발생할 수 있다.

• 각 계층에서 추가적인 데이터와 처리를 더함으로써 비효율이 생길 수 있다.
  • 즉, 데이터를 주고 받을 때, 추가적인 정보(헤더)를 붙여야 한다.

1. 복잡한 시스템 처리:
   • 복잡한 네트워크 시스템을 계층으로 나눠서 각 계층의 기능을 명확하게 정의할 수 있음.
2. 모듈화의 장점:
   • 계층 구조 덕분에 한 계층의 구현을 변경하더라도 다른 계층에 영향을 미치지 않음. 이를 통해 시스템 유지보수 및 업데이트가 용이해짐.
3. 계층화의 단점:
   • 계층 구조는 중복된 기능을 초래할 수 있음. 예를 들어, 오류 검출 기능이 여러 계층에서 중복되어 있을 수 있음. 또한, 각 계층에서 추가되는 오버헤드로 인해 성능 저하가 발생할 수 있음.

🍪 ISO/OSI reference model

컴퓨터 네트워크가 데이터를 어떻게 주고 받는지 설명하기 위해 만든 7계층 구조의 reference model이다. 각 계층은 독립적이며, 계층간 상호작용을 통해 data를 주고 받는다.

1. Application (응용)
2. Presentation (표현)
3. Session (세션)
4. Transport (전송)
5. Network (네트워크)
6. Data Link (데이터 링크)
7. Physical (물리)

Presentation

data를 사용자에게 이해할 수 있는 형태로 변환한다. 예를 들어, 데이터 암호화 혹은 텍스트를 ASCII 코드로 변환한다.

Session

두 장치가 통신하는 동안 연결 세션을 관리하고, 유지한다.

→ 위의 Presentation과 Session 계층은 특정 상황에서만 필요할 때 사용한다.

🍪 Internet protocol stack

인터넷 프로토콜 스택은 OSI 모델보다 간소화 된 5계층 모델로 이루어져있다.

1. Application (응용) - 5계층
   1. 한 종단 system에 있는 application이 다른 종단 system에 있는 application과 정보 패킷을 교환할 때 이 프로토콜을 사용한다.
   2. IMAP, SMTP, HTTP
2. Transport (전송) - 4계층
   1. data를 주고 받을 수 있게 한다.
   2. TCP, UDP
3. Network (네트워크) - 3계층
   1. 데이터를 송수신 할 경로를 찾아주며, IP주소와 라우팅을 담당한다.
   2. IP, routing protocols
4. Link (데이터 링크) - 2계층
   1. 인접한 네트워크 장치간의 데이터 전송을 담당한다.
   2. Ethernet, Wifi, PPP
5. Physical (물리) - 1계층
   1. 물리적 매체를 통해 데이터를 전송한다.

🍪 Encapsulation / Decapsulation

데이터를 안전하고 효율적으로 전달하기 위한 핵심 개념이다.

네트워크에서 데이터가 전송될 때, 각 계층은 데이터를 처리 하면서 자신만의 헤더를 추가하는 캡슐화 과정을 거친다.
그리고 수신 측에서 이 헤더들을 제거하는 역캡슐화 과정을 거쳐 데이터가 상위 계층으로 전달된다.

• Encapsulation : higher → lower (헤더를 붙여가는 과정)
• Decapsulation : lower → higher (헤더를 떼가는 과정)

Encapsulation

1. Application Layer: 사용자가 입력한 데이터가 메시지로 전송됨.
2. Transport Layer: 메시지에 세그먼트가 추가됨.
3. Network Layer: 세그먼트에 IP 헤더를 추가하여 데이터그램이 됨.
4. Link Layer: 프레임 헤더와 프레임 트레일러가 추가됨.
5. Physical Layer: 비트로 변환되어 물리적 매체를 통해 전송됨.

Decapsulation

수신 측에서는 이 과정을 역순으로 수행함. 물리 계층에서 받은 비트 데이터를 링크 계층에서 프레임으로 처리하고, 네트워크 계층에서 데이터그램으로 변환하여 목적지까지 도달함.

Chapter 1.5 : Performance: loss, delay, throughput

인터넷을 통해 파일을 전송하고, 이메일을 보내고, 웹사이트에 접속하는 등 다양한 작업을 수행한다. 하지만 실제 네트워크 환경에서는 데이터가 즉시 전송되거나 손실 없이 완벽하게 전달되는 것이 불가능하다.

패킷 스위칭 네트워크는 데이터 전송 속도를 제한하고, 지연을 유발하며, 경우에 따라 Packet Loss가 되기도 한다.

🌱 Packet delay: four sources

1. 처리 지연(Processing Delay) : determine output link

• - router가 packet을 수신하면 먼저 packet의 header를 확인하고, 해당 packet을 어느 경로로 보낼지 결정한다. (이 때 소요되는 시간이 처리지연)
• 라우터의 성능에 따라 달라지며, 일반적으로 매우 짧은 시간이 소요됨

2. 대기 지연(Queuing Delay) : 패킷을 전송하기 위해 대기하는 시간

• 패킷이 라우터에 도착했을 때, 해당 패킷을 전송하기 위해 대기하는 시간을 의미한다.
• 라우터가 바쁘거나, 트래픽이 많은 경우 패킷은 전송되기 전, 대기열에서 기다려야 한다.
• 이 Queuing Delay는 트래픽의 양에 따라 달라지며, 네트워크의 혼잡도에 따라 지연 시간이 크게 증가할 수 있다.

3. 전송 지연(Transmission Delay) : 라우터에서 링크로 데이터를 보내기 위해 패킷의 모든 비트를 ‘밀어 넣는’데 걸리는 시간

• L : packet length (bits)
• R : link transmission rate (bps)
• Transmission Delay = L/R

4. 전파 지연(Propagation Delay) : 데이터가 물리적 매체를 통해 이동하는 데 소요되는 시간

• 패킷이 링크를 통해 다음 라우터로 전파되는 데 걸리는 시간
• 거리에 비례한다.
• 매체의 전파 속도에 따라 결정된다.
• 일반적으로 빛의 속도에 가깝다.

🌱 Packet queueing delay (revisited)

traffic intensity : 패킷이 대기열에서 대기하는 시간에 영향을 미침

traffic intensity = La/R (a : 패킷 도착률)

• La/R ≈ 0: 패킷이 거의 대기하지 않고 전송되며, 평균 지연 시간도 작음.
• La/R → 1: 대기 시간이 급격히 증가함.
• La/R > 1: 패킷 도착률이 처리 능력을 초과하므로 대기 시간이 무한대로 증가하거나 패킷이 손실될 수 있음.
• 그래서 우리는 traffic intensity가 1보다 크지 않게 설계해야 한다.
• traceroute라는 프로그램은 delay를 측정할 수 있게 하는 프로그램이다.

🌱 Packet loss

• queue의 용량이 유한하기 때문이다.
• full queue에 들어오면 packet을 drop한다.
• 버려진 packet은 retransmitted 된다.

🌱 Throughput (처리량)

주어진 시간 동안 네트워크를 통해 전송되는 데이터의 양을 의미한다.

• 처리량은 여러 요인에 의해 결정되는데, 특히 네트워크 상의 가장 병목 링크(bottleneck link_가장 느린 구간)에 의해 제한된다.
  • 즉, 서버와 클라이언트를 연결하는 모든 링크 중 가장 낮은 전송속도를 가진 링크가 전체 처리량을 결정하게 된다.

처리량 결정

각 연결의 처리량은 다음 세 가지 값 중 가장 작은 값에 의해 결정된다.

• Rc : 수신자의 수신 속도
• Rs : 송신자의 송신 속도
• R/10 : 백본 링크(R)의 대역폭이 10개의 연결로 공평하게 분배되었을 때 각 연결에 할당되는 대역폭처리량은 min(Rc, Rs, R/10)으로 결정.
• 즉, 이 세 가지 값 중 가장 작은 것이 그 연결의 처리량을 제한함.

throughput = min ( Rc, Rs, R/10)